Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id

[Matt Wilson <msw@xxxxxxxxx>]

On Thu, Dec 11, 2014 at 07:00:55PM +0000, Andrew Cooper wrote:
> On 11/12/14 18:19, Matt Wilson wrote:
> > On Wed, Dec 10, 2014 at 10:36:18AM +0000, Andrew Cooper wrote:
> >> On 10/12/14 06:00, Matt Wilson wrote:
> >>> That's not strictly true. You can use the processor index in ACPI.
> >> The LAPIC objects in the MADT/APIC table?  That is still constructed
> >> with the broken LAPIC_ID = 2 * processor_id logic.
> > Have you checked on an EC2 instance (for example: C3, I2, R3)?
> 
> I meant in terms of upstream code.  I will believe you when you say that
> those instances do it differently.
> 
> My point was that the processor index is only as accurate as hvmloader
> makes it, and upstream, this relies on the broken logic.
> 
> Even if hvmloader is altered and does things differently, it is still
> bogus to draw any inference of vcpu_id from processor id.

hvmloader accurately sets the processor_id in the MADT LAPIC tables to
the correct vcpu_id value (by chance, though things would not work if
this was not so).

hvmloader/acpi/build.c:
>    for ( i = 0; i < nr_processor_objects; 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 = ((i < hvm_info->nr_vcpus) &&
>                        test_bit(i, hvm_info->vcpu_online)
>                        ? ACPI_LOCAL_APIC_ENABLED : 0);
>        lapic++;
>    }

See also hvmloader/config.h:
> #define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)

See how Keir called this "vcpu_id"?

--msw

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