Re: [Qemu-devel] Re: RFC: emulation of system flash

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

Auf 10.03.2011 23:58, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Right, the constant size argument is definitely a point we need to talk
>> about.
>>
>> We could sidestep the issue by always using a 16 MByte flash device
>> which gets filled from the top with the firmware image, but I'm not sure
>> if that has other side effects.
>> Another way to solve this would be to emulate multiple flash chips, one
>> per power-of-two size between 128 kB and 16 MB. Some SPI flash chip
>> families encode the size into their ID, so determining the size
>> algorithmically is as simple as calculating
>> 1 << idbyte3
>> and emulating this is equally simple.
>>     
> Power of 2 from 128kb to 16MB sounds reasonable to me.
>
> How would the SPI host controller be discovered?

PCI ID of the ISA bridge of the chipset. AFAIK most flashing programs
out there use that criterion. There is one drawback, though: We should
use an interface which works well for all emulated chipsets in Qemu, and
that may a bit harder.
Is there a way to get PCI IDs of all emulated chipsets in Qemu so I can
take a look if there is a chance to to this correctly?



> Would the firmware
> be able to depend on having control of the device at OS runtime?  This
> would be needed for UEFI non-volatile variables to make sure they can
> always be written.
>   

UEFI _should not_ have control of the device at OS runtime on real
hardware for security reasons, unless UEFI slipped a rootkit into the
OS. Not sure about Windows, but I'm pretty sure Linux will not run any
UEFI code (except maybe during early init).

Think flash update. If some flash update software runs under your OS of
choice, and UEFI is allowed to perform read/write accesses to flash at
the same time, you will get random corruption. You could do it like some
AMD chipsets, and provide some sort of semaphore for flash access
coordination between a flash updater and the BIOS/EFI, but I don't think
any Intel chipset can do that. Newer Intel chipsets allow locking out
flash accesses not coming from the management engine, but UEFI does not
run in the management engine, so that feature won't help us here.

That said, if any OS out there indeed runs UEFI code regularly during OS
runtime, and that UEFI code wants to access flash, it has to hope that
nobody else is trying to access flash at the same time. An easy way out
would be to use the ACPI NVS region while the machine is running an OS,
but changes would not automatically be persistent without help from the
OS or some ACPI handler on shutdown.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/