This patch adds two scenarios to the vmexit test. One is a very simple
PIO case that is handled in the kernel (reading from ELCR). The other
is an unmapped PIO that is handled in userspace. The difference
between the two is roughly the cost of a userspace exit; the existing
inl_from_pmtimer test is not precise enough, because the device model
has a pretty high cost.
With the current code in KVM, the difference between inl_from_kernel
and vmcall is the cost of emulation. This is arguably a bug, because
inl_from_kernel need not go through the whole emulation stuff.
Example:
vmcall 3898
inl_from_pmtimer 24615
inl_from_qemu 20574
inl_from_kernel 7237
So the cost of exiting to userspace is 13000 cycles on this machine,
and the cost of emulation is 3300 cycles.
Suggested-by: Avi Kivity <avi.kivity@xxxxxxxxx>
Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
---
x86/vmexit.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/x86/vmexit.c b/x86/vmexit.c
index ad8ab55..545a8bc 100644
--- a/x86/vmexit.c
+++ b/x86/vmexit.c
@@ -4,6 +4,13 @@
#include "processor.h"
#include "atomic.h"
+static unsigned int inb(unsigned short port)
+{
+ unsigned int val;
+ asm volatile("xorl %0, %0; inb %w1, %b0" : "=a"(val) : "Nd"(port));
+ return val;
+}
+
static unsigned int inl(unsigned short port)
{
unsigned int val;
@@ -82,6 +89,16 @@ static void inl_pmtimer(void)
inl(0xb008);
}
+static void inl_nop_qemu(void)
+{
+ inl(0x1234);
+}
+
+static void inl_nop_kernel(void)
+{
+ inb(0x4d0);
+}
+
static void ple_round_robin(void)
{
struct counter {
@@ -116,6 +133,8 @@ static struct test {
{ mov_to_cr8, "mov_to_cr8" , .parallel = 1, },
#endif
{ inl_pmtimer, "inl_from_pmtimer", .parallel = 1, },
+ { inl_nop_qemu, "inl_from_qemu", .parallel = 1 },
+ { inl_nop_kernel, "inl_from_kernel", .parallel = 1 },
{ ipi, "ipi", is_smp, .parallel = 0, },
{ ipi_halt, "ipi+halt", is_smp, .parallel = 0, },
{ ple_round_robin, "ple-round-robin", .parallel = 1 },
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
