From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v3] KVM: nVMX: Improve I/O exit handling Date: Mon, 18 Feb 2013 09:53:22 +0100 Message-ID: <5121EC02.30704@web.de> References: <51180635.3060003@web.de> <20130211100721.GA11107@fermat.math.technion.ac.il> <5118C4F9.707@web.de> <5118D3B5.5010406@siemens.com> <20130214093257.GK9817@redhat.com> <511D30FF.10108@siemens.com> <5121CB15.10206@web.de> <20130218084446.GX9817@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AVIMXXUIPRLBGAEFUGSN" Cc: Marcelo Tosatti , Nadav Har'El , kvm , Orit Wasserman To: Gleb Natapov Return-path: Received: from mout.web.de ([212.227.17.11]:56590 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753398Ab3BRIxb (ORCPT ); Mon, 18 Feb 2013 03:53:31 -0500 In-Reply-To: <20130218084446.GX9817@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AVIMXXUIPRLBGAEFUGSN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-02-18 09:44, Gleb Natapov wrote: > On Mon, Feb 18, 2013 at 07:32:53AM +0100, Jan Kiszka wrote: >> On 2013-02-14 19:46, Jan Kiszka wrote: >>> This prevents trapping L2 I/O exits if L1 has neither unconditional n= or >>> bitmap-based exiting enabled. Furthermore, it implements basic I/O >>> bitmap handling. Repeated string accesses are still reported to L1 >>> unconditionally for now. >>> >>> Signed-off-by: Jan Kiszka >>> --- >>> >>> Changes in v3: >>> - trap unconditionally if bitmap access fails >>> >>> arch/x86/kvm/vmx.c | 55 ++++++++++++++++++++++++++++++++++++++++++= ++++++++- >>> 1 files changed, 53 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>> index 6667042..2633199 100644 >>> --- a/arch/x86/kvm/vmx.c >>> +++ b/arch/x86/kvm/vmx.c >>> @@ -5908,6 +5908,58 @@ static int (*const kvm_vmx_exit_handlers[])(st= ruct kvm_vcpu *vcpu) =3D { >>> static const int kvm_vmx_max_exit_handlers =3D >>> ARRAY_SIZE(kvm_vmx_exit_handlers); >>> =20 >>> +static bool nested_vmx_exit_handled_io(struct kvm_vcpu *vcpu, >>> + struct vmcs12 *vmcs12) >>> +{ >>> + unsigned long exit_qualification; >>> + gpa_t bitmap, last_bitmap; >>> + bool string, rep; >>> + 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; >>> + >>> + exit_qualification =3D vmcs_readl(EXIT_QUALIFICATION); >>> + >>> + string =3D exit_qualification & 16; >>> + rep =3D exit_qualification & 32; >>> + >>> + /* TODO: interpret instruction and check range against bitmap */ >>> + if (string && rep) >>> + return 1; >> >> Nonsense, rep ins/outs always works against the same port. We can simp= ly >> drop this check and be done with the feature. I'll come up with v4. >> > Actually this reminds me that we should check range of ports depending > on operand size, not one port. But here is a catch, older cpus do not > provide operand size as part of exit information. You mean what bit 54 in VMX_BASIC is telling us? Too bad. OK, will write v5 which takes this into account. Jan ------enig2AVIMXXUIPRLBGAEFUGSN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEh7AIACgkQitSsb3rl5xTrKwCgpqWVJvWDAd5/JRa/ra25O73z ETkAn0aoWmC2l6Q8EZMnlDsePFo3h8Q5 =uAps -----END PGP SIGNATURE----- ------enig2AVIMXXUIPRLBGAEFUGSN--