On Tue, Feb 07, 2017 at 03:00:32PM +0100, Igor Mammedov wrote: > On Mon, 6 Feb 2017 19:41:36 +0200 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > On Mon, Feb 06, 2017 at 09:29:30AM -0800, Ben Warren wrote: > > > > > > On Feb 6, 2017, at 8:15 AM, Michael S. Tsirkin <m...@redhat.com> > > > wrote: > > > > > > On Sun, Feb 05, 2017 at 01:12:00AM -0800, b...@skyportsystems.com > > > wrote: > > > > > > From: Ben Warren <b...@skyportsystems.com> > > > > > > This implements the VM Generation ID feature by passing a 128-bit > > > GUID to the guest via a fw_cfg blob. > > > Any time the GUID changes, an ACPI notify event is sent to the > > > guest > > > > > > The user interface is a simple device with one parameter: > > > - guid (string, must be "auto" or in UUID format > > > xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) > > > > > > Signed-off-by: Ben Warren <b...@skyportsystems.com> > > > > [...] > > > > > > > This variable name was suggested by Laszlo. the ‘a’ in ‘vgia’ refers to > > > address, but I’ll add some comments. > > > > vmgenid_addr_le? > > > > > > > How about we make it 8 byte so it's future proof? > > > > > > I can do that, but a previous conversation we had made it clear that > > > guests > > > would never allocate above 4GB so 64 bits wasn’t necessary. > > > > Right, it's just very painful to change once we make it 32 bit. > I'd keep it 32 bit since it's in variable in global AML context and our > table revision is 1, so per spec OSPM should handle it as 32 number. > Chances of guest survival on boot would depend on AML interpreter tolerance > to AML errors, which for windows usually is 0 and leads to non obvious BSOD. > If we leave DWORD, even XP will be able to boot fine and only report > unknown device.
AML reports 2 DWORDS per spec, no issue there. I guess it's exactly for XP compatibility.
