From: Jan Kiszka <jan.kis...@siemens.com>

This prevents trapping L2 I/O exits if L1 has neither unconditional nor
bitmap-based exiting enabled. Furthermore, it implements I/O bitmap
handling. We still exit unconditionally in case the CPU does not provide
information for ins/outs.

Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---

Changes in v5:
 - still exit unconditionally if CPU refuses to provide exit
   information on ins/outs

 arch/x86/kvm/vmx.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6667042..ccc7c17 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -651,6 +651,7 @@ static struct vmcs_config {
        int size;
        int order;
        u32 revision_id;
+       u32 vmx_basic_high;
        u32 pin_based_exec_ctrl;
        u32 cpu_based_exec_ctrl;
        u32 cpu_based_2nd_exec_ctrl;
@@ -752,6 +753,11 @@ static inline bool vm_need_tpr_shadow(struct kvm *kvm)
        return (cpu_has_vmx_tpr_shadow()) && (irqchip_in_kernel(kvm));
 }
 
+static inline bool cpu_has_stringio_exit_info(void)
+{
+       return vmcs_config.vmx_basic_high & (VMX_BASIC_INOUT >> 32);
+}
+
 static inline bool cpu_has_secondary_exec_ctrls(void)
 {
        return vmcs_config.cpu_based_exec_ctrl &
@@ -2635,6 +2641,7 @@ static __init int setup_vmcs_config(struct vmcs_config 
*vmcs_conf)
        vmcs_conf->size = vmx_msr_high & 0x1fff;
        vmcs_conf->order = get_order(vmcs_config.size);
        vmcs_conf->revision_id = vmx_msr_low;
+       vmcs_conf->vmx_basic_high = vmx_msr_high;
 
        vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control;
        vmcs_conf->cpu_based_exec_ctrl = _cpu_based_exec_control;
@@ -5908,6 +5915,54 @@ static int (*const kvm_vmx_exit_handlers[])(struct 
kvm_vcpu *vcpu) = {
 static const int kvm_vmx_max_exit_handlers =
        ARRAY_SIZE(kvm_vmx_exit_handlers);
 
+static bool nested_vmx_exit_handled_io(struct kvm_vcpu *vcpu,
+                                      struct vmcs12 *vmcs12)
+{
+       unsigned long exit_qualification;
+       gpa_t bitmap, last_bitmap;
+       u16 port;
+       int size;
+       u8 b;
+
+       if (nested_cpu_has(vmcs12, CPU_BASED_UNCOND_IO_EXITING))
+               return 1;
+
+       if (!nested_cpu_has(vmcs12, CPU_BASED_USE_IO_BITMAPS))
+               return 0;
+
+       /* TODO: for older CPUs, derive access width from instruction */
+       if (!cpu_has_stringio_exit_info())
+               return 1;
+
+       exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+
+       port = exit_qualification >> 16;
+       size = (exit_qualification & 7) + 1;
+
+       last_bitmap = (gpa_t)-1;
+       b = -1;
+
+       while (size > 0) {
+               if (port < 0x8000)
+                       bitmap = vmcs12->io_bitmap_a;
+               else
+                       bitmap = vmcs12->io_bitmap_b;
+               bitmap += (port & 0x7fff) / 8;
+
+               if (last_bitmap != bitmap)
+                       if (kvm_read_guest(vcpu->kvm, bitmap, &b, 1))
+                               return 1;
+               if (b & (1 << (port & 7)))
+                       return 1;
+
+               port++;
+               size--;
+               last_bitmap = bitmap;
+       }
+
+       return 0;
+}
+
 /*
  * Return 1 if we should exit from L2 to L1 to handle an MSR access access,
  * rather than handle it ourselves in L0. I.e., check whether L1 expressed
@@ -6097,8 +6152,7 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
        case EXIT_REASON_DR_ACCESS:
                return nested_cpu_has(vmcs12, CPU_BASED_MOV_DR_EXITING);
        case EXIT_REASON_IO_INSTRUCTION:
-               /* TODO: support IO bitmaps */
-               return 1;
+               return nested_vmx_exit_handled_io(vcpu, vmcs12);
        case EXIT_REASON_MSR_READ:
        case EXIT_REASON_MSR_WRITE:
                return nested_vmx_exit_handled_msr(vcpu, vmcs12, exit_reason);
-- 
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to