qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v5 05/10] ACPI: Add Virtual Machine Generation ID support
Date: Tue, 7 Feb 2017 17:04:56 +0100

On Tue, 7 Feb 2017 17:35:19 +0200
"Michael S. Tsirkin" <address@hidden> 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" <address@hidden> 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 <address@hidden> 
> > > > wrote:
> > > > 
> > > >     On Sun, Feb 05, 2017 at 01:12:00AM -0800, address@hidden wrote:
> > > > 
> > > >         From: Ben Warren <address@hidden>
> > > > 
> > > >         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 <address@hidden>
> > > > 
> > [...]
> > 
> > > > 
> > > > 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 
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]