Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Xen>
  3. Devel
[PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two
paul.durrant at citrix
Nov 29, 2011, 2:53 AM
Post #1 of 8 (216 views)
Permalink
# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563733 0
# Node ID ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
# Parent a9c67c2daf4b0181ef2581471ea920eecb495616
Add an ACPI device exposing a package called ADDR, evaluating to two
integers, and with _CID and _DDN set to "VM_Gen_Counter".

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c Tue Nov 29 10:48:53 2011 +0000
@@ -47,6 +47,7 @@ struct acpi_info {
uint32_t pci_min, pci_len; /* 4, 8 - PCI I/O hole boundaries */
uint32_t madt_csum_addr; /* 12 - Address of MADT checksum */
uint32_t madt_lapic0_addr; /* 16 - Address of first MADT LAPIC struct */
+ uint32_t vm_gid_addr; /* 20 - Address of VM generation id buffer */
};

/* Number of processor objects in the chosen DSDT. */
diff -r a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl Tue Nov 29 10:48:53 2011 +0000
@@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
PMIN, 32,
PLEN, 32,
MSUA, 32, /* MADT checksum address */
- MAPA, 32 /* MADT LAPIC0 address */
+ MAPA, 32, /* MADT LAPIC0 address */
+ VGIA, 32 /* VM generation id address */
}

/* Fix HCT test for 0x400 pci memory:
@@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
IRQNoFlags () {7}
})
}
+
+ Device(VGID) {
+ Name(_HID, "ACPI0001")
+ Name(_UID, 0x00)
+ Name(_CID, "VM_Gen_Counter")
+ Name(_DDN, "VM_Gen_Counter")
+ Method(_STA, 0, NotSerialized)
+ {
+ If(LEqual(\_SB.VGIA, 0x00000000)) {
+ Return(0x00)
+ } Else {
+ Return(0x0F)
+ }
+ }
+ Name(PKG, Package ()
+ {
+ 0x00000000,
+ 0x00000000
+ })
+ Method(ADDR, 0, NotSerialized)
+ {
+ Store(\_SB.VGIA, Index(PKG, 0))
+ Return(PKG)
+ }
+ }
}
}
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
keir.xen at gmail
Nov 29, 2011, 1:19 AM
Post #2 of 8 (201 views)
Permalink
On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com> wrote:

>> I have no problem choosing a different _HID. I just don't have a good
>> reference for what name is not going to clash with something else. Looks
>> like ACPI0001 was a bad guess. Any better suggestions? What are the
>> 'generic PNP device IDs'?
>>
>> Paul
>
> Well I actually brought it up as a discussion point. I have the same sort of
> issue - I have a generic device for a virtualized environment. I don't really
> want it to be recognized as anything specific. I guess I see three options:
>
> - Use an unassigned APCIXXXX string. I believe the _HID string values of the
> form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work
> in the long run.
> - Use one of the predefined generic container EisaId PNP values. By that I
> meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic
> container driver, it doesn't do very much with these devices so that might be
> OK.

This option sounds reasonable. We have freedom to change it in future if it
turns out to be a bad choice, not that I can see why it would be.

-- Keir

> - Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then
> we could carve up the product number part of the ID as we see fit.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
keir.xen at gmail
Nov 29, 2011, 3:13 AM
Post #3 of 8 (205 views)
Permalink
Pick a name and I can fix it up. :-)

-- Keir

On 29/11/2011 17:25, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

> Keir,
>
> Do you want me to re-send that patch or will you fix it up?
>
> Paul
>
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Sent: 29 November 2011 09:20
>> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing
>> a package called ADDR, evaluating to two
>>
>> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
>> wrote:
>>
>>>> I have no problem choosing a different _HID. I just don't have a
>> good
>>>> reference for what name is not going to clash with something
>> else.
>>>> Looks like ACPI0001 was a bad guess. Any better suggestions? What
>> are
>>>> the 'generic PNP device IDs'?
>>>>
>>>> Paul
>>>
>>> Well I actually brought it up as a discussion point. I have the
>> same
>>> sort of issue - I have a generic device for a virtualized
>> environment.
>>> I don't really want it to be recognized as anything specific. I
>> guess I see three options:
>>>
>>> - Use an unassigned APCIXXXX string. I believe the _HID string
>> values
>>> of the form "ACPIXXXX" are defined by the ACPI specs themselves so
>>> this may not work in the long run.
>>> - Use one of the predefined generic container EisaId PNP values.
>> By
>>> that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
>> the
>>> Linux generic container driver, it doesn't do very much with these
>>> devices so that might be OK.
>>
>> This option sounds reasonable. We have freedom to change it in
>> future if it turns out to be a bad choice, not that I can see why it
>> would be.
>>
>> -- Keir
>>
>>> - Acquire a vendor specific EisaId range for Xen (e.g.
>>> EisaId(XENABCD)). Then we could carve up the product number part
>> of the ID as we see fit.
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
Ross.Philipson at citrix
Nov 29, 2011, 7:14 AM
Post #4 of 8 (206 views)
Permalink
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: Tuesday, November 29, 2011 5:53 AM
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
>
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322563733 0 # Node
> ID ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
> # Parent a9c67c2daf4b0181ef2581471ea920eecb495616
> Add an ACPI device exposing a package called ADDR, evaluating to two
> integers, and with _CID and _DDN set to "VM_Gen_Counter".
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> diff -r a9c67c2daf4b -r ac68bd6d4853
> tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c Mon Nov 28 11:57:23 2011
> +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c Tue Nov 29 10:48:53 2011
> +0000
> @@ -47,6 +47,7 @@ struct acpi_info {
> uint32_t pci_min, pci_len; /* 4, 8 - PCI I/O hole boundaries */
> uint32_t madt_csum_addr; /* 12 - Address of MADT checksum */
> uint32_t madt_lapic0_addr; /* 16 - Address of first MADT LAPIC
> struct */
> + uint32_t vm_gid_addr; /* 20 - Address of VM generation id
> buffer */
> };
>
> /* Number of processor objects in the chosen DSDT. */ diff -r
> a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl Mon Nov 28 11:57:23 2011
> +0000
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl Tue Nov 29 10:48:53 2011
> +0000
> @@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
> PMIN, 32,
> PLEN, 32,
> MSUA, 32, /* MADT checksum address */
> - MAPA, 32 /* MADT LAPIC0 address */
> + MAPA, 32, /* MADT LAPIC0 address */
> + VGIA, 32 /* VM generation id address */
> }
>
> /* Fix HCT test for 0x400 pci memory:
> @@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
> IRQNoFlags () {7}
> })
> }
> +
> + Device(VGID) {
> + Name(_HID, "ACPI0001")
> + Name(_UID, 0x00)
> + Name(_CID, "VM_Gen_Counter")
> + Name(_DDN, "VM_Gen_Counter")
> + Method(_STA, 0, NotSerialized)
> + {
> + If(LEqual(\_SB.VGIA, 0x00000000)) {
> + Return(0x00)
> + } Else {
> + Return(0x0F)
> + }
> + }
> + Name(PKG, Package ()
> + {
> + 0x00000000,
> + 0x00000000
> + })
> + Method(ADDR, 0, NotSerialized)
> + {
> + Store(\_SB.VGIA, Index(PKG, 0))
> + Return(PKG)
> + }
> + }
> }
> }
> }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Paul, perhaps a different _HID might be better. Per the 3.0 spec, ACPI0001 is for SMBus host controller device; this might lead to some confusion for an OSPM. Maybe one of the generic PNP device IDs or perhaps we need a manufacturer ID for Xen?

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
Paul.Durrant at citrix
Nov 29, 2011, 8:05 AM
Post #5 of 8 (204 views)
Permalink
> -----Original Message-----
> From: Ross Philipson
[snip]
>
> Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> ACPI0001 is for SMBus host controller device; this might lead to
> some confusion for an OSPM. Maybe one of the generic PNP device IDs
> or perhaps we need a manufacturer ID for Xen?
>

I have no problem choosing a different _HID. I just don't have a good reference for what name is not going to clash with something else. Looks like ACPI0001 was a bad guess. Any better suggestions? What are the 'generic PNP device IDs'?

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
Ross.Philipson at citrix
Nov 29, 2011, 8:29 AM
Post #6 of 8 (205 views)
Permalink
> -----Original Message-----
> From: Paul Durrant
> Sent: Tuesday, November 29, 2011 11:05 AM
> To: Ross Philipson; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
>
> > -----Original Message-----
> > From: Ross Philipson
> [snip]
> >
> > Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> > ACPI0001 is for SMBus host controller device; this might lead to some
> > confusion for an OSPM. Maybe one of the generic PNP device IDs or
> > perhaps we need a manufacturer ID for Xen?
> >
>
> I have no problem choosing a different _HID. I just don't have a good
> reference for what name is not going to clash with something else. Looks
> like ACPI0001 was a bad guess. Any better suggestions? What are the
> 'generic PNP device IDs'?
>
> Paul

Well I actually brought it up as a discussion point. I have the same sort of issue - I have a generic device for a virtualized environment. I don't really want it to be recognized as anything specific. I guess I see three options:

- Use an unassigned APCIXXXX string. I believe the _HID string values of the form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work in the long run.
- Use one of the predefined generic container EisaId PNP values. By that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic container driver, it doesn't do very much with these devices so that might be OK.
- Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then we could carve up the product number part of the ID as we see fit.

Anyway, just some ideas.

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
Paul.Durrant at citrix
Nov 29, 2011, 9:25 AM
Post #7 of 8 (207 views)
Permalink
Keir,

Do you want me to re-send that patch or will you fix it up?

Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 29 November 2011 09:20
> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing
> a package called ADDR, evaluating to two
>
> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
> wrote:
>
> >> I have no problem choosing a different _HID. I just don't have a
> good
> >> reference for what name is not going to clash with something
> else.
> >> Looks like ACPI0001 was a bad guess. Any better suggestions? What
> are
> >> the 'generic PNP device IDs'?
> >>
> >> Paul
> >
> > Well I actually brought it up as a discussion point. I have the
> same
> > sort of issue - I have a generic device for a virtualized
> environment.
> > I don't really want it to be recognized as anything specific. I
> guess I see three options:
> >
> > - Use an unassigned APCIXXXX string. I believe the _HID string
> values
> > of the form "ACPIXXXX" are defined by the ACPI specs themselves so
> > this may not work in the long run.
> > - Use one of the predefined generic container EisaId PNP values.
> By
> > that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
> the
> > Linux generic container driver, it doesn't do very much with these
> > devices so that might be OK.
>
> This option sounds reasonable. We have freedom to change it in
> future if it turns out to be a bad choice, not that I can see why it
> would be.
>
> -- Keir
>
> > - Acquire a vendor specific EisaId range for Xen (e.g.
> > EisaId(XENABCD)). Then we could carve up the product number part
> of the ID as we see fit.
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two [ In reply to ]
Ross.Philipson at citrix
Nov 29, 2011, 12:53 PM
Post #8 of 8 (214 views)
Permalink
I have been using EisaId(PNP0A06) in my device without any noticeable ill effect. I see that one in use in various DSDT's I have picked apart too (though I don't see the 0A05 one). So it gets my vote.

Thanks
Ross

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Tuesday, November 29, 2011 6:14 AM
> To: Paul Durrant; Ross Philipson; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
>
> Pick a name and I can fix it up. :-)
>
> -- Keir
>
> On 29/11/2011 17:25, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:
>
> > Keir,
> >
> > Do you want me to re-send that patch or will you fix it up?
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.xen@gmail.com]
> >> Sent: 29 November 2011 09:20
> >> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> >> package called ADDR, evaluating to two
> >>
> >> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
> >> wrote:
> >>
> >>>> I have no problem choosing a different _HID. I just don't have a
> >> good
> >>>> reference for what name is not going to clash with something
> >> else.
> >>>> Looks like ACPI0001 was a bad guess. Any better suggestions? What
> >> are
> >>>> the 'generic PNP device IDs'?
> >>>>
> >>>> Paul
> >>>
> >>> Well I actually brought it up as a discussion point. I have the
> >> same
> >>> sort of issue - I have a generic device for a virtualized
> >> environment.
> >>> I don't really want it to be recognized as anything specific. I
> >> guess I see three options:
> >>>
> >>> - Use an unassigned APCIXXXX string. I believe the _HID string
> >> values
> >>> of the form "ACPIXXXX" are defined by the ACPI specs themselves so
> >>> this may not work in the long run.
> >>> - Use one of the predefined generic container EisaId PNP values.
> >> By
> >>> that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
> >> the
> >>> Linux generic container driver, it doesn't do very much with these
> >>> devices so that might be OK.
> >>
> >> This option sounds reasonable. We have freedom to change it in future
> >> if it turns out to be a bad choice, not that I can see why it would
> >> be.
> >>
> >> -- Keir
> >>
> >>> - Acquire a vendor specific EisaId range for Xen (e.g.
> >>> EisaId(XENABCD)). Then we could carve up the product number part
> >> of the ID as we see fit.
> >>
> >
>


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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal