Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device

[Paolo Bonzini <pbonzini@redhat.com>]

On 28/05/2015 15:24, Michael S. Tsirkin wrote:
> On Thu, May 28, 2015 at 03:00:52PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 28/05/2015 14:21, Michael S. Tsirkin wrote:
>>>> And the way I can fix it would be...? Is there another memory region I can
>>>> use?
>>>>
>>>> Thanks,
>>>>
>>>>     Gal.
>>>
>>> I think we hammered out an interesting alternative off-list: get hold of
>>> some AddressRegionNVS memory and copy data from MMIO or port io over
>>> there when you get an interrupt.
>>
>> That doesn't work because there's no way to get the base address of a
>> DataTableRegion.
>>
>> You could use a linker ADD_POINTER command, but it wouldn't work for
>> UEFI.
> 
> Hmm why not? UEFI runs these as well.

But it only uses them to find a pointer to the base of the tables.  The
actual relocation is done by the platform-independent UEFI libraries.

So you would have the following:

1) OVMF loads the loader script and resolves the pointers.  ADDR now
correctly points inside the table that has the VMGENID.

2) OVMF calls the AcpiProtocol->InstallAcpiTable, which _copies_ the
tables to memory that it allocates.  The type of memory is correct (NVS)
but the ADDR is now wrong because it points inside the old copy.

3) OVMF notices that the loader script has a pointer to inside the UEFI
table.  So it does not free the table, but this doesn't help: the
DataTableRegion points to the copy of the table, but ADDR points to the
original.  Whenever the GPE event runs, it writes the VMGENID into the
copy of the table, not into ADDR.

It's a pity, yes, but it's very hard to fix.

Paolo

>>  So I think it's best to just stay with this one.  If we do find
>> something better we can always change it later.
>>
>> Paolo