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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.09.17 at 16:13, <roger.pau@xxxxxxxxxx> wrote:
> 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.

Indeed.

> 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).

Why? An ACPI or APIC ID is still fine as long as it does only occur
in x2APIC contexts.

Jan


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