Re: [Xen-devel] [Xen-users] FreeBSD PVHVM call for testing

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-05-29 at 15:10 -0700, Matt Wilson wrote:
> On Wed, May 29, 2013 at 06:25:56PM +0100, Ian Campbell wrote:
> > On Wed, 2013-05-29 at 19:03 +0200, Roger Pau Monnà wrote:
> > > 
> > > Since I'm not able to reproduce the cpuid != acpi_id case, could you
> > > give it a try and report the results?
> > 
> > Konrad,
> > 
> > Might this same problem be related to the issue you saw doing PVHVM VCPU
> > hotplug which you mentioned the other day?
> >
> > In general for HVM I suppose there isn't a strict relationship between
> > the CPU number the kernel chooses for a CPU (which is somewhat
> > arbitrarily up to the kernel) and the hypervisors VCPU number (which is
> > exposed via the virtual APIC ID).
> 
> The CPU enumeration should follow the ACPI ID order in MADT (or
> MP-table), right?

You mean the guest's enumeration? I'd have thought that was entirely up
to the guest. Using the APIC ID might be a reasonable implementation but
there are surely others (e.g. collapsing sparse LAPIC IDs into
contiguous cpu ids, using the top bits for NUMA node, etc etc).

>   The local APIC ID (returned by cpuid
> EAX=0000_0001h => EBX bits 31:24) shouldn't be used for
> enumeration. Under Xen, the LAPIC ID is hardcoded to vCPU idx * 2:
> 
> void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
> [...]
>      case 0x1:
>          /* Fix up VLAPIC details. */
>          *ebx &= 0x00FFFFFFu;
>          *ebx |= (v->vcpu_id * 2) << 24;
> [...]
>      case 0xb:
>          /* Fix the x2APIC identifier. */
>          *edx = v->vcpu_id * 2;
>          break;
> 
> This isn't the way it works on some of our EC2 instances.  On our high
> performance instance types, we provide x2APIC IDs that distinguish
> threads, cores and sockets to provide the guest OS with CPU topology
> information. The OS and applications can use CPUID EAX=0000_000Bh,
> ECX=level (HT=0, Core=1, Socket=2) => EAX bits 4:0 to determine the
> topology.

Hrm, that does beg the question of how an HVM guest is supposed to
determine what Xen's idea of the VCPU number is for a given CPU.

I can't see anything which reverses that * 2 on the vcpu_op path and I
don't suppose you implemented the inverse of your scheme.

Ian.


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