From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: jbeulich@suse.com, keir@xen.org, jun.nakajima@intel.com,
eddie.dong@intel.com, ian.jackson@eu.citrix.com,
stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com
Cc: yang.z.zhang@intel.com, andrew.cooper3@citrix.com,
boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: [PATCH v5 0/4] Expose HW APIC virtualization support to HVM guests
Date: Tue, 18 Mar 2014 20:58:30 -0400 [thread overview]
Message-ID: <1395190714-3802-1-git-send-email-boris.ostrovsky@oracle.com> (raw)
Version 5:
* Remember to deal with Viridian leaves in xc_cpuid_constrain()
Version 4:
* asm changes per Jan's suggestions
* Don't pass leaf index number to handlers, check for sub_idx==0
* Added (possibly somewhat overwrought) interface to constrain user-requested
CPUID to what is allowed (specifically, for leaf 0x40000000 only EAX[7:0]
can be ovverwritten).
Version 3:
* Removed sysctl for querying hypervisor leaf from libxc, replaced it with
prefixed CPUID instruction
* Limited ability change hypervisor leaves to 0x40000000
* Fixed IS_HYPERVISOR_LEAF macro
Version 2:
* Added ability to specify hypervisor CPUID leaves in config file (this requires
new sysctl)
* Use 2 bits to indicate what is supported --- one for APIC memory access and the
other for x2APIC. Still not sure whether virtual interrupt delivery should be
exposed as well.
HVM guests running on HW that supports HW APIC virtualization features
(APIC-register virtualization, virtual interrupt delivery, etc) may
want to use APIC instead of hvm_pirqs. Since we are not guaranteed to
have these features on VMX (for example, there is a boot option to
turn it off) and there is no such support on SVM we need to make the
guest aware that its APIC accesses may not be so bad.
CPUID seems to be a good way to provide this info to the guest.
Having a guest switch to APIC shows fairly good impact on number of
VMEXITs. For example, with a pass-through NIC, netperf sees almost
half as many. Here are results for 'xentrace -e 0x00083fff -c 2 -D -T 2'
(The guest here essentially turned off XENFEAT_hvm_pirqs but we may
want to use APIC for MSI interrupts only and leave pirqs for gsi).
[root@ovs105 virt]# cat orig |xentrace_format ~/xen/tools/xentrace/formats | awk '{print $5}' | sort | uniq -c
94 cpu_change
13944 HLT
26341 INJ_VIRQ
12054 INTR
30784 INTR_WINDOW
10126 TRAP
124783 VMENTRY
124782 VMEXIT
59217 VMMCALL
35 wrap_buffer
[root@ovs105 virt]# cat apicv |xentrace_format ~/xen/tools/xentrace/formats | awk '{print $5}' | sort | uniq -c
49 cpu_change
16157 HLT
31 INJ_VIRQ
10652 INTR
38 INTR_WINDOW
10 NPF
10286 TRAP
71269 VMENTRY
71269 VMEXIT
34129 VMMCALL
15 wrap_buffer
The difference is even larger when the guest is busy.
These results are in line with what has been reported for KVM. For example
http://events.linuxfoundation.org/sites/events/files/cojp13_natapov.pdf
http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/2012-lpc-virt-intel-vt-feat-nakajima.pdf
I am also not sure whether (cpu_has_vmx_apic_reg_virt &
cpu_has_vmx_virtualize_x2apic_mode) is sufficient to declare full HW
APIC support to a guest. The tests show ~95K VMEXITs when virtual
interrupt delivery and posted interrupts are turned off so there
appears to still be some benefit. I suppose we can use another CPUID
bit for these two (although I am not particularly eager to do this).
Boris Ostrovsky (4):
xen/libxc: Allow changes to hypervisor CPUID leaf from config file
x86/hvm: Revert 80ecb40362365ba77e68fc609de8bd3b7208ae19
x86/hvm: Add HVM-specific hypervisor CPUID leaf
x86/hvm: Indicate avaliability of HW support of APIC virtualization
to HVM guests
tools/libxc/xc_cpuid_x86.c | 71 ++++++++++++++++++++++++++++++++++-
xen/arch/x86/domain.c | 19 ++++++++--
xen/arch/x86/hvm/hvm.c | 9 +++++
xen/arch/x86/hvm/vmx/vmx.c | 15 ++++++++
xen/arch/x86/traps.c | 18 ++++-----
xen/include/asm-x86/domain.h | 7 ++++
xen/include/asm-x86/hvm/hvm.h | 7 ++++
xen/include/public/arch-x86/cpuid.h | 10 +++++
8 files changed, 142 insertions(+), 14 deletions(-)
--
1.7.10.4
next reply other threads:[~2014-03-19 0:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 0:58 Boris Ostrovsky [this message]
2014-03-19 0:58 ` [PATCH v5 1/4] xen/libxc: Allow changes to hypervisor CPUID leaf from config file Boris Ostrovsky
2014-03-19 9:26 ` Jan Beulich
2014-03-19 9:29 ` Ian Campbell
2014-03-19 14:26 ` Boris Ostrovsky
2014-03-19 9:27 ` Ian Campbell
2014-03-19 9:32 ` Jan Beulich
2014-03-19 9:52 ` Ian Campbell
2014-03-19 10:06 ` Jan Beulich
2014-03-19 10:39 ` Ian Campbell
2014-03-19 11:44 ` Jan Beulich
2014-03-19 12:02 ` Ian Campbell
2014-03-19 14:41 ` Boris Ostrovsky
2014-03-20 9:25 ` Ian Campbell
2014-03-20 13:50 ` Boris Ostrovsky
2014-03-19 0:58 ` [PATCH v5 2/4] x86/hvm: Revert 80ecb40362365ba77e68fc609de8bd3b7208ae19 Boris Ostrovsky
2014-03-19 0:58 ` [PATCH v5 3/4] x86/hvm: Add HVM-specific hypervisor CPUID leaf Boris Ostrovsky
2014-03-19 0:58 ` [PATCH v5 4/4] x86/hvm: Indicate avaliability of HW support of APIC virtualization to HVM guests Boris Ostrovsky
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=1395190714-3802-1-git-send-email-boris.ostrovsky@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
/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.