From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: x86: Save&restore interrupt shadow mask Date: Sun, 14 Feb 2010 18:06:07 +0100 Message-ID: <4B782D7F.2040102@web.de> References: <4B782980.8070300@web.de> <4B782B66.4090205@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC32571AF7FF4AC2D2958A3E3" Cc: Marcelo Tosatti , kvm To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:47071 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751974Ab0BNRLT (ORCPT ); Sun, 14 Feb 2010 12:11:19 -0500 In-Reply-To: <4B782B66.4090205@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC32571AF7FF4AC2D2958A3E3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 02/14/2010 06:49 PM, Jan Kiszka wrote: >> From: Jan Kiszka >> >> The interrupt shadow created by STI or MOV-SS-like operations is part = of >> the VCPU state and must be preserved across migration. Transfer it in >> the spare padding field of kvm_vcpu_events.interrupt. >> >> As a side effect we now have to make vmx_set_interrupt_shadow robust >> against both shadow types being set. Give MOV SS a higher priority and= >> skip STI in that case to avoid that VMX throws a fault on next entry. >> >> >> diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h >> index f46b79f..4dd01e2 100644 >> --- a/arch/x86/include/asm/kvm.h >> +++ b/arch/x86/include/asm/kvm.h >> @@ -258,6 +258,9 @@ struct kvm_reinject_control { >> #define KVM_VCPUEVENT_VALID_NMI_PENDING 0x00000001 >> #define KVM_VCPUEVENT_VALID_SIPI_VECTOR 0x00000002 >> >> +#define X86_SHADOW_INT_MOV_SS 1 >> +#define X86_SHADOW_INT_STI 2 >> + >> =20 >=20 > svm doesn't make a difference. Is it worth exposing this to userspace > (and thus providing wrong information on svm)? SVM already folds both reasons into one. Don't know if we should do it at the generic layer already - probably. >=20 > (in any case, needs a KVM_ prefix). =2E..and then this is no longer required. OK, will export this with boolean meaning. >=20 > Needs a KVM_CAP_ and flags bit. Why if merged before 2.6.33? We haven't released KVM_CAP_VCPU_EVENTS yet.= Jan --------------enigC32571AF7FF4AC2D2958A3E3 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkt4LYQACgkQitSsb3rl5xTHAwCePz4l4JJqHQ3PKuA4OEYrELSc RaUAn2O0axqXVjlMinVpg9x5LrvM7r4S =uE3J -----END PGP SIGNATURE----- --------------enigC32571AF7FF4AC2D2958A3E3--