On Tue, Feb 07, 2017 at 05:04:56PM +0100, Igor Mammedov wrote: > On Tue, 7 Feb 2017 17:35:19 +0200 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > 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. > > it's only ADDR method thought but we are talking about > Named DWORD vs QWORD VGIA variable which is patched by linker command
Oh sorry. Yes, you want to keep that one a DWORD. Does not affect the interface. So write 64 bits into fw cfg, but patch 32 bits into AML. -- MST