[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |