From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: nSVM: interception checks on emulation (was: [PATCH] KVM: nSVM: Fix IOIO size reported on emulation) Date: Mon, 30 Jun 2014 11:27:48 +0200 Message-ID: <53B12D94.2060900@web.de> References: <53B128B9.1030205@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBpnnoVaOHOcAMBLwMWU60k0IVNhXNeWL" Cc: Joerg Roedel , Valentine Sinitsyn To: Paolo Bonzini , kvm Return-path: Received: from mout.web.de ([212.227.17.11]:49868 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbaF3J1x (ORCPT ); Mon, 30 Jun 2014 05:27:53 -0400 In-Reply-To: <53B128B9.1030205@web.de> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gBpnnoVaOHOcAMBLwMWU60k0IVNhXNeWL Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2014-06-30 11:07, Jan Kiszka wrote: > I'm seeing one more issue now: on emulation of "in (%dx),%eax", we leav= e > to user space several times and check interception also several times Correction: we only leave once for user space. > after returning. We use dx to calculate the port number for the > interception check. But at some point, user space (QEMU) decides to > update that register during vmport access - and now we check the wrong > port in the bitmap (namely port 0). Ideas? >=20 > In general, the same interception checks are done multiple times. Once > after the exit, then again during emulation. Can't we avoid this someho= w? >=20 OK, we have different interception stages, but it seems we take multiple ones when we should only take a single: qemu-system-x86-4455 [000] 38083.617545: kvm_exit: reason E= XIT_IOIO rip 0x7fc6ead774e4 info 56580241 7fc6ead774e5 qemu-system-x86-4455 [000] 38083.617547: kvm_nested_vmexit: rip 7fc6= ead774e4 reason EXIT_IOIO info1 56580241 info2 7fc6ead774e5 int_info 0 in= t_info_err 0 qemu-system-x86-4455 [000] 38083.617548: bprint: nested_s= vm_intercept: 5658 4 3c00bacb 0 1 f qemu-system-x86-4455 [000] 38083.617549: bprint: nested_s= vm_intercept: f0 qemu-system-x86-4455 [000] 38083.617553: kvm_emulate_insn: 0:7fc6ea= d774e4: ed qemu-system-x86-4455 [000] 38083.617555: bprint: svm_chec= k_intercept: 5658 2 4 43 qemu-system-x86-4455 [000] 38083.617556: bprint: nested_s= vm_intercept: 5658 4 3c00bacb 0 1 f qemu-system-x86-4455 [000] 38083.617556: bprint: nested_s= vm_intercept: f0 qemu-system-x86-4455 [000] 38083.617559: kvm_userspace_exit: reason K= VM_EXIT_IO (2) qemu-system-x86-4455 [000] 38083.617567: bprint: kvm_arch= _vcpu_ioctl_get_regs: 5658 qemu-system-x86-4455 [000] 38083.617598: bprint: kvm_arch= _vcpu_ioctl_set_regs: 0 qemu-system-x86-4455 [000] 38083.617628: bprint: svm_chec= k_intercept: 0 2 4 43 qemu-system-x86-4455 [000] 38083.617629: bprint: nested_s= vm_intercept: 0 4 3c00b000 0 1 f qemu-system-x86-4455 [000] 38083.617630: bprint: nested_s= vm_intercept: ff qemu-system-x86-4455 [000] 38083.617631: kvm_nested_vmexit_inject: reas= on EXIT_IOIO info1 241 info2 7fc6ead774e4 int_info 0 int_info_err 0 And you can also see the rdx writing of user space here (rdx is printed in kvm_arch_vcpu_ioctl_*). Jan --gBpnnoVaOHOcAMBLwMWU60k0IVNhXNeWL 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxLZUACgkQitSsb3rl5xRtIACg0McEVWuDcO/IgPyuCWPYQ03E Gv4An1X8lP2XTsz8leg9QDueIf7CSr9b =zpZp -----END PGP SIGNATURE----- --gBpnnoVaOHOcAMBLwMWU60k0IVNhXNeWL--