[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |