Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.07.16 at 17:34, <konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
>> >>> On 29.06.16 at 18:27, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>> >> To explain better what I'm trying to suggest here please take a look at
>> >> the attached patch. If we can guarantee long term that ACPI id always
>> >> equals to Xen's idea of vCPU id this is probably the easiest way.
>> >>
>> >> -- Vitaly
>> > 
>> > The code in hvmloader which sets up the MADT does:
>> > 
>> >     for ( i = 0; i < hvm_info->nr_vcpus; i++ )
>> >     {
>> >         memset(lapic, 0, sizeof(*lapic));
>> >         lapic->type    = ACPI_PROCESSOR_LOCAL_APIC;
>> >         lapic->length  = sizeof(*lapic);
>> >         /* Processor ID must match processor-object IDs in the DSDT. */
>> >         lapic->acpi_processor_id = i;
>> >         lapic->apic_id = LAPIC_ID(i);
>> >         lapic->flags = (test_bit(i, hvm_info->vcpu_online)
>> >                         ? ACPI_LOCAL_APIC_ENABLED : 0);
>> >         lapic++;
>> >     }
>> > 
>> > So relying on the acpi_processor_id does look to be reliable.  That code
>> > hasn't changed since 2007, and that was only a bugfix.  I would go so
>> > far as to say it is reasonable for us to guarantee this in the guest ABI.
>> 
>> In fact - is there any other way a guest could learn the vCPU IDs
>> of its CPUs in a reliable way? I don't think so, and hence this de
>> facto already is part of the ABI; we should of course spell it out
>> somewhere.
> 
> CCing Joao.
> 
> Joao worked (and I think he posted an RFC patchset?) where this is changed so
> that the true hardware topology (core, thread, etc) is exposed. This is 
> obviously
> for cases where you want pinning.
> 
> I would hesistate to spell this out as an ABI..

Are you perhaps mixing up ACPI and APIC IDs? Here talk is of the
former, while Joao's patch set was about the latter iirc.

Jan


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