All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests
Date: Thu, 10 Nov 2016 16:24:48 +0000	[thread overview]
Message-ID: <1f1721ef-523d-8d75-2c42-5169ac717343@citrix.com> (raw)
In-Reply-To: <16108e74-2fd5-738c-b747-a93d4ae143e6@oracle.com>

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@citrix.com> 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@oracle.com>
>>> 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@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-11-10 16:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10 14:50 [PATCH for-4.8] libxc/x86: Report consistent initial APIC value for PV guests Boris Ostrovsky
2016-11-10 14:55 ` Andrew Cooper
2016-11-10 15:05   ` Boris Ostrovsky
2016-11-10 15:08     ` Andrew Cooper
2016-11-10 15:24       ` Boris Ostrovsky
2016-11-10 16:12   ` Jan Beulich
2016-11-10 16:24     ` Boris Ostrovsky
2016-11-10 16:24       ` Andrew Cooper [this message]
2016-11-11 15:16 ` Wei Liu
2016-11-11 15:32   ` Jan Beulich
2016-11-11 15:33     ` Andrew Cooper
2016-11-12  6:46       ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f1721ef-523d-8d75-2c42-5169ac717343@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.