Re: [Qemu-devel] [PATCH v5 05/10] ACPI: Add Virtual Machine Generation ID support

["Michael S. Tsirkin" <mst@redhat.com>]

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" <mst@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" <mst@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 <mst@redhat.com> wrote:
> > > > > 
> > > > >     On Sun, Feb 05, 2017 at 01:12:00AM -0800, ben@skyportsystems.com wrote:
> > > > > 
> > > > >         From: Ben Warren <ben@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 <ben@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