Re: [Xen-devel] [PATCH] Add code to track the address of the VM generation id buffer across a

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2011-12-01 at 11:54 +0000, Paul Durrant wrote:
> Would the following be sufficient?
> 
>   Paul
> 
> diff -r 62ff6a318c5d docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5     Wed Nov 30 16:59:58 2011 -0800
> +++ b/docs/man/xl.cfg.pod.5     Thu Dec 01 11:52:58 2011 +0000
> @@ -484,6 +484,12 @@ of Xen) within a Xen guest or to support
>  which uses hardware virtualisation extensions (e.g. Windows XP
>  compatibility mode on more modern Windows OS).
> 
> +=item B<generation_id=NUMBER>
> +
> +This value will be exposed inside the guest at an address which
> +can be determined by evaluating the ADDR package of an ACPI device
> +with _CID "VM_Gen_Counter".

Belongs more in the "Support for Paravirtualisation of HVM Guests"
section, which is just below? The "Processor and Platform Features" is
more about things which are optional (at least in theory) on real
systems.

Since the semantics of the number itself are up to the toolstack and
this toolstack defers this requirement up to the user it should probably
also say something along the lines of:

        The semantics of this value are guest dependent and it is up to
        the user to ensure those semantics are met.

(even better would be to implement something meaningful in xl,
obviously)

Ian.

> +
>  =back
> 
>  =head3 Guest Virtual Time Controls
> diff -r 62ff6a318c5d tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl    Wed Nov 30 16:59:58 2011 -0800
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl    Thu Dec 01 11:52:58 2011 +0000
> @@ -398,6 +398,25 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                      })
>                  }
> 
> +                /* VM Generation ID Device
> +                 *
> +                 * The basic requirements of this device are as follows:
> +                 *
> +                 * - It must be exposed somewhere in ACPI namespace with a 
> _CID of
> +                 *   "VM_Gen_Counter".
> +                 * - It must also include a _DDN of "VM_Gen_Counter".
> +                 * - It must contain a _HID object but no particular value is
> +                 *   required.
> +                 * - It must expose a package called ADDR which evaluates to 
> two
> +                 *   integers; the first being the low order 32-bits of a 
> guest
> +                 *   physical address (GPA), the second by the high order 
> 32-bits of
> +                 *   the GPA. This GPA is the address of an 8-byte aligned 
> 8-byte
> +                 *   buffer containing the VM generation ID.
> +                 *   This buffer must not be in ranges supported as 
> AddressRangeMemory
> +                 *   or AddressRangeACPI and must not be mapped by any PTE 
> with caching
> +                 *   disabled. (See the code in 
> tools/firmware/hvmloader/acpi/build.c
> +                 *   which determines the address and contents of the 
> buffer).
> +                 */
>                  Device(VGID) {
>                      Name(_HID, EisaID ("PNP0A06"))
>                      Name(_UID, 0x00)
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 01 December 2011 10:00
> > To: Paul Durrant
> > Cc: Konrad Rzeszutek Wilk; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] [PATCH] Add code to track the address of
> > the VM generation id buffer across a
> > 
> > On Thu, 2011-12-01 at 09:47 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 01 December 2011 08:59
> > > > To: Paul Durrant
> > > > Cc: Konrad Rzeszutek Wilk; xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [Xen-devel] [PATCH] Add code to track the address
> > of
> > > > the VM generation id buffer across a
> > > >
> > > > On Thu, 2011-12-01 at 08:46 +0000, Paul Durrant wrote:
> > > > > Konrad,
> > > > >
> > > > >   Did you see my previous patch set? The introductory comment
> > was:
> > > >
> > > >
> > > > I think that description belongs somewhere permanent, either in
> > > > docs/misc or as a comment in an appropriate header.
> > > >
> > >
> > > Good point. Perhaps I should stick the comment just above the
> > device description in the dsdt?
> > 
> > That would do I guess.
> > 
> > I guess more important would be the user facing toolstack specific
> > semantics/documentation i.e. the manpage.
> > 
> > Ian.
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel