Re: [Qemu-devel] Virtual Machine Generation ID

[Ben Warren <ben@skyportsystems.com>]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]


> On Jan 17, 2017, at 7:21 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> Let's not top-post anymore pls.
> 
> On Tue, Jan 17, 2017 at 07:01:27AM -0800, Ed Swierk wrote:
>> You mean what causes the guest to re-read the vmgenid guid? The
>> vmgenid ACPI table defines a notify method, and when the guest
>> receives the corresponding event, it re-reads the guid. (Also it
>> appears that with Windows Server 2012 at least, if no notify method is
>> defined, as is the case with Xen, the guest just re-reads it on
>> demand.)
>> 
>> Wouldn't it be sufficient for the qmp set-vmgenid command to call
>> acpi_ram_update() with the new guid, and acpi_send_event() to notify
>> the guest?
>> 
>> --Ed
>> 
> 
> Not if you want to reliably be able to know that gen ID
> did not change.
> 
> Consider an application that sends a transaction to
> a database. It should be able to read gen ID and if that
> is unchanged then you know you only sent it once.
> If that is changed you may have sent it twice,
> and may need to recover.
> 
> If guest updates gen id in memory after getting a notify,
> there's a window after receiving a notify and before
> updating it.
> 
> 
Guests don’t update gen ID, the value is read-only to Windows.  The spec states:

“Put the generation ID in an 8-byte aligned buffer in guest RAM, ROM or device memory space, which is guaranteed not to be used by the operating system”

The host is in complete control of the data, so as long as the notify event follows setting of the data, there should be no race.  In practice, the only time the value will change in a running guest is when recovering a snapshot.
> 
> -- 
> MST
—Ben


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3583 bytes --]