On 二, 2019-06-11 at 17:11 +0100, Sudeep Holla wrote:
> On Tue, Jun 11, 2019 at 10:03:15AM -0600, Al Stone wrote:
> >
> > On 6/11/19 6:53 AM, Sudeep Holla wrote:
> > >
> > > On Mon, Jun 10, 2019 at 02:07:34PM -0600, Al Stone wrote:
> > > >
> > > > In the ACPI specification, section 6.1.12, a _UID may be either
> > > > an
> > > > integer or a string object. Up until now, when defining
> > > > processor
> > > > Device()s in ACPI (_HID ACPI0007), only integers were allowed
> > > > even
> > > > though this ignored the specification. As a practical matter,
> > > > it
> > > > was not an issue.
> > > >
> > > > Recently, some DSDTs have shown up that look like this:
> > > >
> > > > Device (XX00)
> > > > {
> > > > Name (_HID, "ACPI0007" /* Processor Device */)
> > > > Name (_UID, "XYZZY-XX00")
> > > > .....
> > > > }
> > > >
> > > > which is perfectly legal. However, the kernel will report
> > > > instead:
> > > >
> > > I am not sure how this can be perfectly legal from specification
> > > perspective. It's legal with respect to AML namespace but then
> > > the
> > > other condition of this matching with entries in static tables
> > > like
> > > MADT is not possible where there are declared to be simple 4 byte
> > > integer/word. Same is true for even ACPI0010, the processor
> > > container
> > > objects which need to match entries in PPTT,
> > >
> > > ACPI Processor UID(in MADT): The OS associates this GICC(applies
> > > even
> > > for APIC and family) Structure with a processor device object in
> > > the namespace when the _UID child object of the processor device
> > > evaluates to a numeric value that matches the numeric value in
> > > this
> > > field.
> > >
> > > So for me that indicates it can't be string unless you have some
> > > ways to
> > > match those _UID entries to ACPI Processor ID in MADT and PPTT.
> > >
> > > Let me know if I am missing to consider something here.
> > >
> > > --
> > > Regards,
> > > Sudeep
> > >
> > Harumph. I think what we have here is a big mess in the spec, but
> > that is exactly why this is an RFC.
> >
> > The MADT can have any of ~16 different subtables, as you note. Of
> > those, only these require a numeric _UID:
> >
> > -- Type 0x0: Processor Local APIC
> > -- Type 0x4: Local APIC NMI [0]
> > -- Type 0x7: Processor Local SAPIC [1]
> > -- Type 0x9: Processor Local x2APIC
> > -- Type 0xa: Local x2APIC NMI [0]
> > -- Type 0xb: GICC
> >
> > Note [0]: a value of !0x0 is also allowed, indicating all
> > processors
> > [1]: this has two fields that could be interpreted as an ID
> > when
> > used together
> >
> > It does not appear that you could build a usable system without any
> > of these subtables -- but perhaps someone knows of incantations
> > that
> > could -- which is why I thought a string _UID might be viable.
> >
> I hope no one is shipping such device yet or am I wrong ?
> We can ask them to fix as Linux simply can't boot on such system or
> even if it boots, it may have issues with acpi_processor drivers.
>
> >
> > If we consider the PPTT too, then yeah, _UID must be an integer for
> > some devices.
> >
> > Thanks for the feedback; it forced me to double-check my thinking
> > about
> > the MADT. The root cause of the issue is not the kernel in this
> > case,
> > but a lack of clarity in the spec -- or at least implied
> > requirements
> > that probably need to be explicit. I'll send in a spec change.
> >
> Completely agreed. Even little more clarification on this is helpful.
> Thanks for volunteering :) to take up spec change, much appreciated.
>
hmmm, we've run into the same problem, and I think the problem is that
1. this is a BIOS bug, because we do need numeric _UID when using
"Device" object, because we need to use it as a reference to find the
processor APIC ID in MADT. Thus a BIOS fix is indeed needed in this
case.
2. Although ACPI spec has made "Processor" object deprecated, it does
not provide a clear ASL example about how to use "Device" object, plus
the clarification of this is in the MADT section instead of the
"Declare Processors" section, which could be easy overlooked, thus I
totally agree with you that we need some spec change here. Thanks!
-rui
> --
> Regards,
> Sudeep
