All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Andy Lutomirski <luto@kernel.org>,
	x86@kernel.org
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Borislav Petkov <bp@alien8.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Brian Gerst <brgerst@gmail.com>,
	Matthew Whitehead <tedheadster@gmail.com>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Peter Zijlstra <peterz@infradead.org>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Juergen Gross <JGross@suse.com>
Subject: Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation
Date: Fri, 2 Dec 2016 15:09:31 -0500	[thread overview]
Message-ID: <1d68c6dd-df69-ffc0-bb36-10b4b76bb2fb@oracle.com> (raw)
In-Reply-To: <a9c41f3a-f649-712e-21bb-a849b0a4de13@citrix.com>

On 12/02/2016 06:44 AM, Andrew Cooper wrote:
> On 02/12/16 00:35, Andy Lutomirski wrote:
>> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't
>> guaranteed to serialize.  (Even CPUID isn't *really* guaranteed to
>> serialize on Xen PV, but, in practice, any trap it generates will
>> serialize.)
> Well, Xen will enabled CPUID Faulting wherever it can, which is
> realistically all IvyBridge hardware and newer.
>
> All hypercalls are a privilege change to cpl0.  I'd hope this condition
> is serialising, but I can't actually find any documentation proving or
> disproving this.
>
>> On my laptop, CPUID(eax=1, ecx=0) is ~83ns and IRET-to-self is
>> ~110ns.  But Xen PV will trap CPUID if possible, so IRET-to-self
>> should end up being a nice speedup.
>>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>

Executing CPUID in an HVM guest is quite expensive since it will cause a
VMEXIT. (And that should be true for any hypervisor, at least on Intel.
On AMD it's configurable)

-boris

WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Andy Lutomirski <luto@kernel.org>,
	x86@kernel.org
Cc: Juergen Gross <JGross@suse.com>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Peter Zijlstra <peterz@infradead.org>,
	Brian Gerst <brgerst@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matthew Whitehead <tedheadster@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation
Date: Fri, 2 Dec 2016 15:09:31 -0500	[thread overview]
Message-ID: <1d68c6dd-df69-ffc0-bb36-10b4b76bb2fb@oracle.com> (raw)
In-Reply-To: <a9c41f3a-f649-712e-21bb-a849b0a4de13@citrix.com>

On 12/02/2016 06:44 AM, Andrew Cooper wrote:
> On 02/12/16 00:35, Andy Lutomirski wrote:
>> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't
>> guaranteed to serialize.  (Even CPUID isn't *really* guaranteed to
>> serialize on Xen PV, but, in practice, any trap it generates will
>> serialize.)
> Well, Xen will enabled CPUID Faulting wherever it can, which is
> realistically all IvyBridge hardware and newer.
>
> All hypercalls are a privilege change to cpl0.  I'd hope this condition
> is serialising, but I can't actually find any documentation proving or
> disproving this.
>
>> On my laptop, CPUID(eax=1, ecx=0) is ~83ns and IRET-to-self is
>> ~110ns.  But Xen PV will trap CPUID if possible, so IRET-to-self
>> should end up being a nice speedup.
>>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>

Executing CPUID in an HVM guest is quite expensive since it will cause a
VMEXIT. (And that should be true for any hypervisor, at least on Intel.
On AMD it's configurable)

-boris

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

  parent reply	other threads:[~2016-12-02 20:09 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 20:34 [PATCH 0/4] CPUID-less CPU fixes and improvements Andy Lutomirski
2016-11-30 20:34 ` [PATCH 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels Andy Lutomirski
2016-11-30 20:34 ` [PATCH 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing" Andy Lutomirski
2016-12-01  5:53   ` Peter Zijlstra
2016-12-01  9:02     ` Borislav Petkov
2016-12-01 10:07       ` Thomas Gleixner
2016-12-01 11:15         ` [PATCH] x86/CPU: Add X86_FEATURE_CPUID Borislav Petkov
2016-12-01 17:00           ` Andy Lutomirski
2016-12-02  0:33       ` [PATCH 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing" Andy Lutomirski
2016-12-01 17:00     ` Andy Lutomirski
2016-11-30 20:34 ` [PATCH 3/4] x86/microcode/intel: Replace sync_core() with cpuid_eax(1) Andy Lutomirski
2016-12-01  9:11   ` Borislav Petkov
2016-11-30 20:34 ` [PATCH 4/4] x86/asm: Change sync_core() to use MOV to CR2 to serialize Andy Lutomirski
2016-12-01  9:22   ` Borislav Petkov
2016-12-01 17:08     ` Andy Lutomirski
2016-12-01 17:46       ` Andrew Cooper
2016-12-02  7:34     ` Ingo Molnar
2016-12-02  0:34 ` [PATCH v2 0/6] CPUID-less CPU/sync_core fixes and improvements Andy Lutomirski
2016-12-02  0:34   ` [PATCH v2 1/6] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels Andy Lutomirski
2016-12-02  0:34   ` [PATCH v2 2/6] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing" Andy Lutomirski
2016-12-02  0:34   ` [PATCH v2 3/6] x86/microcode/intel: Replace sync_core() with cpuid_eax(1) Andy Lutomirski
2016-12-02  0:35   ` [PATCH v2 4/6] x86/paravirt: Make sync_core() be a paravirt op Andy Lutomirski
2016-12-02  0:35   ` [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation Andy Lutomirski
2016-12-02 11:44     ` Andrew Cooper
2016-12-02 11:44     ` Andrew Cooper
2016-12-02 17:07       ` Andy Lutomirski
2016-12-02 17:07       ` Andy Lutomirski
2016-12-02 17:16         ` Andrew Cooper
2016-12-02 17:16         ` Andrew Cooper
2016-12-02 17:23           ` Andy Lutomirski
2016-12-02 17:26             ` Andrew Cooper
2016-12-02 17:26             ` Andrew Cooper
2016-12-02 17:23           ` Andy Lutomirski
2016-12-02 18:50       ` Boris Ostrovsky
2016-12-02 18:50       ` Boris Ostrovsky
2016-12-02 19:34         ` Andy Lutomirski
2016-12-02 19:34         ` Andy Lutomirski
2016-12-02 20:09       ` Boris Ostrovsky [this message]
2016-12-02 20:09         ` Boris Ostrovsky
2016-12-02 17:32     ` Linus Torvalds
2016-12-02 17:38       ` Andy Lutomirski
2016-12-02 17:53         ` Linus Torvalds
2016-12-02 18:03         ` Borislav Petkov
2016-12-02 18:27           ` Linus Torvalds
2016-12-02 18:50             ` Borislav Petkov
2016-12-02 19:03               ` Linus Torvalds
2016-12-02 19:20                 ` Borislav Petkov
2016-12-02 19:24                   ` Linus Torvalds
2016-12-02 19:28                     ` Borislav Petkov
2016-12-03 15:02                       ` [PATCH] x86/alternatives: Do not use sync_core() to serialize I$ Borislav Petkov
2016-12-03 17:05                         ` Andy Lutomirski
2016-12-20  7:58                         ` [tip:x86/urgent] " tip-bot for Borislav Petkov
2016-12-20  9:35                         ` tip-bot for Borislav Petkov
2016-12-02 19:30                     ` [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation Andy Lutomirski
2016-12-02 19:35                       ` Linus Torvalds
2016-12-02 20:41                         ` Andy Lutomirski
2016-12-02 21:10                           ` Linus Torvalds
2016-12-02 22:55                             ` Andy Lutomirski
2016-12-02 23:09                               ` Linus Torvalds
2016-12-02 19:23                 ` Andy Lutomirski
2016-12-02 19:30                   ` Borislav Petkov
2016-12-03 12:44         ` Borislav Petkov
2016-12-02  0:35   ` [PATCH v2 6/6] x86/asm: Change sync_core() to use MOV to CR2 to serialize Andy Lutomirski
2016-12-02  0:36 ` [PATCH 0/4] CPUID-less CPU fixes and improvements Andy Lutomirski
2016-12-02 10:17   ` Ingo Molnar

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=1d68c6dd-df69-ffc0-bb36-10b4b76bb2fb@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=JGross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tedheadster@gmail.com \
    --cc=x86@kernel.org \
    --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.