Re: [Qemu-devel] [edk2] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive

[Laszlo Ersek <lersek@redhat.com>]

On 11/26/13 14:41, Paolo Bonzini wrote:
> Il 25/11/2013 20:45, Laszlo Ersek ha scritto:
>> From looking at "hw/block/pflash_cfi01.c", it seems that the guest can
>> interrogate the flash device about its size (nb_blocs is stored in
>> cfi_table starting at 0x2D, and cfi_table can be queried by command 0x98
>> in pflash_read()). So, if the guest cares, it can figure out that there
>> are multiple devices backing the range. I think.
> 
> IIUC in the case of OVMF the guest "just knows" that there are multiple
> devices backing the range.  Is that right?

No, the guest (the flash driver) is unaware of that. It could know if it
wanted to, but it doesn't care. It cares about a base address and a
size, and that range is subdivided into various roles. But how many
flash devices back the range is not interesting for the driver.

Jordan wrote the driver with one flash device in mind, and when I split
the image in two parts, I took care to map them so that the base
address, the size, and those boundaries stay the same. It's sufficient
for the driver to continue working.

> But yes, I think that the guest can figure out that there are multiple
> devices backing the range.  From reading the pflash code further:
> 
> * the pflash device doesn't care about the location where you write the
> command (the exception is the "block erase" command)
> 
> * the pflash device only cares about the LSB you read from when you read
> data from it
> 
> So you can use the last 256 bytes of the first flash (you know it ends
> at 4GB) to check for the device (there's probably some suggested
> protocol to do that, I don't know) and query its size.  Example with
> "-qtest stdio":
> 
> writeb 0xffffff00 0x98
> OK
> readb 0xfffffff2d
> OK 0x000000000000001f
> readb 0xfffffff2e
> OK 0x0000000000000000
> readb 0xfffffff2f
> OK 0x0000000000000010
> readb 0xfffffff30
> OK 0x0000000000000000
> writeb 0xffffff00 0x98
> OK
> 
> This means the device has 31+1 blocks each 4KB in size.  You can then
> query the next device at 4GB-128KB-256, and so on.

Thanks for testing this in practice.
Laszlo