Re: [Xen-devel] [RFC PATCH V3 2/3] Tool/ACPI: DSDT extension to support more vcpus

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Sep 19, 2017 at 07:55:32AM -0600, Jan Beulich wrote:
> >>> On 19.09.17 at 15:48, <roger.pau@xxxxxxxxxx> wrote:
> > On Tue, Sep 19, 2017 at 07:44:21AM -0600, Jan Beulich wrote:
> >> >>> On 19.09.17 at 15:29, <roger.pau@xxxxxxxxxx> wrote:
> >> > On Wed, Sep 13, 2017 at 12:52:48AM -0400, Lan Tianyu wrote:
> >> >> +        if ( apic_id > 254 )
> >> > 
> >> > 255? An APIC ID of 255 should still be fine.
> >> 
> >> Wasn't it you who (validly) asked for the boundary to be 254, due
> >> to 0xff being the broadcast value?
> > 
> > But that's the ACPI ID, not the APIC ID.
> 
> The code above says "apic_id" - is the variable mis-named? Or am
> I reading your reply the wrong way round, in which case the question
> would be why an ACPI ID could ever express something like
> "broadcast"?

Yes, sorry I got messed up. This is indeed fine, as a local APIC ID
of 255 is the broadcast ID. But this also applies to the ACPI ID,
since an ACPI ID of 255 is also the broadcast ID for local APIC
entries in the MADT. For example a Local APIC NMI Structure with an
ACPI ID of 255 applies to all local APICs.

We need to be careful to not create local APIC entries with either
APIC or ACPI ID equal to 255 (and to also not create Processor objects
with ACPI ID of 255).

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel