All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	"Nadav Har'El" <nyh@math.technion.ac.il>,
	kvm <kvm@vger.kernel.org>, Orit Wasserman <owasserm@redhat.com>
Subject: Re: [PATCH v5] KVM: nVMX: Improve I/O exit handling
Date: Mon, 18 Feb 2013 11:36:56 +0200	[thread overview]
Message-ID: <20130218093656.GZ9817@redhat.com> (raw)
In-Reply-To: <5121F19A.5030506@web.de>

On Mon, Feb 18, 2013 at 10:17:14AM +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@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.kiszka@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;
> +

Sigh, actually I am stupid :( The information that is not available
on older cpus is address size in "VM-exit instruction information",
not operand size on exit qualification, so your v4 is correct. Except
handling of port wrap around:

  If the “use I/O bitmaps” VM-execution control is 1, the instruction
  causes a VM exit if it attempts to access an I/O port corresponding to a
  bit set to 1 in the appropriate I/O bitmap (see Section 24.6.4). If an
  I/O operation “wraps around” the 16-bit I/O-port space (accesses
  ports FFFFH and 0000H), the I/O instruction causes a VM exit (the
  “unconditional I/O exiting” VM-execution control is ignored if the
  “use I/O bitmaps” VM-execution control is 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

--
			Gleb.

  reply	other threads:[~2013-02-18  9:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-10 20:42 [PATCH] KVM: nVMX: Improve I/O exit handling Jan Kiszka
2013-02-11 10:07 ` Nadav Har'El
2013-02-11 10:16   ` Jan Kiszka
2013-02-11 11:19     ` [PATCH v2] " Jan Kiszka
2013-02-14  9:32       ` Gleb Natapov
2013-02-14 11:19         ` Jan Kiszka
2013-02-14 12:11           ` Gleb Natapov
2013-02-14 12:22             ` Jan Kiszka
2013-02-14 12:56               ` Gleb Natapov
2013-02-14 13:54                 ` Nadav Har'El
2013-02-14 14:44                   ` Gleb Natapov
2013-02-14 18:46         ` [PATCH v3] " Jan Kiszka
2013-02-17  8:55           ` Gleb Natapov
2013-02-18  6:32           ` Jan Kiszka
2013-02-18  6:45             ` [PATCH v4] " Jan Kiszka
2013-02-18  8:44             ` [PATCH v3] " Gleb Natapov
2013-02-18  8:53               ` Jan Kiszka
2013-02-18  8:57                 ` Gleb Natapov
2013-02-18  9:17                   ` [PATCH v5] " Jan Kiszka
2013-02-18  9:36                     ` Gleb Natapov [this message]
2013-02-18 10:02                       ` Jan Kiszka
2013-02-18 10:21                         ` [PATCH v6] " Jan Kiszka
2013-02-18 10:32                           ` Gleb Natapov
2013-02-19  2:13                             ` Marcelo Tosatti

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=20130218093656.GZ9817@redhat.com \
    --to=gleb@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=nyh@math.technion.ac.il \
    --cc=owasserm@redhat.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.