[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests



On 10/11/16 16:24, Boris Ostrovsky wrote:
> On 11/10/2016 11:12 AM, Jan Beulich wrote:
>>>>> On 10.11.16 at 15:55, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 10/11/16 14:50, Boris Ostrovsky wrote:
>>>> Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
>>>> APIC ID) with contents of that field on the processor that launched
>>>> the guest. This results in the guest reporting different initial
>>>> APIC IDs across runs.
>>>>
>>>> We should be consistent in how this value is reported, let's set
>>>> it to 0 (which is also what Linux guests expect).
>>>>
>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>>> This surely wants to go along with:
>>>
>>> andrewcoop@andrewcoop:/local/xen.git/xen$ git diff
>>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>>> index b51b51b..bdf9339 100644
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -985,6 +985,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
>>>          uint32_t tmp, _ecx, _ebx;
>>>  
>>>      case 0x00000001:
>>> +        /* Fix up VLAPIC details. */
>>> +        b &= 0x00FFFFFFu;
>>> +        b |= (curr->vcpu_id * 2) << 24;
>>> +
>>>          c &= pv_featureset[FEATURESET_1c];
>>>          d &= pv_featureset[FEATURESET_1d];
>>>  
>>>
>>> Which brings the PV CPUID handling in line with HVM handling.  Otherwise
>>> a guest will see an APIC ID of 0 in all vcpus, which will surely confuse it.
>> Which will still result in multiple identical APIC IDs once there are
>> 128 or more vCPU-s in a PV guest.

You can already crash Xen with fewer PV vcpus than that, due to long
running for_each_vcpu() loops.

The current ABI limit of 8192 is implausible for production, as is the
current 128 limit for HVM guests.

>
> And this change (either with or without *2) makes Linux PV problem of
> mismatched APIC[0x20] vs CPUID(1).EBX[31:24] to be back (yes, because
> Linux is broken in that it currently makes APIC[0x20] return zero).
>
> You'd obviously be within your rights to say that it's up to Linux to
> deal with this but I will ask you to consider taking only the toolstack
> part of this for now.

If the toolstack along is sufficient duct tape, perhaps best to go with
just that for now.

I will have to change all of this for CPUID phase-2.  We can see about
fixing things more correctly then.

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.