From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2] KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates Date: Tue, 08 Dec 2009 22:17:06 +0100 Message-ID: <4B1EC252.9040009@web.de> References: <4B1BE216.2090407@web.de> <4B1BE452.6090107@redhat.com> <4B1BE8BF.7030404@web.de> <20091208140249.GA19154@amt.cnet> <4B1E5DA4.3010605@redhat.com> <20091208205240.GA24565@amt.cnet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig065955635672F736FE4F3094" Cc: Avi Kivity , Jan Kiszka , kvm , Gleb Natapov To: Marcelo Tosatti Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:35014 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966331AbZLHVRE (ORCPT ); Tue, 8 Dec 2009 16:17:04 -0500 In-Reply-To: <20091208205240.GA24565@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig065955635672F736FE4F3094 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marcelo Tosatti wrote: > On Tue, Dec 08, 2009 at 04:07:32PM +0200, Avi Kivity wrote: >> On 12/08/2009 04:02 PM, Marcelo Tosatti wrote: >>> On Sun, Dec 06, 2009 at 06:24:15PM +0100, Jan Kiszka wrote: >>> =20 >>>> User space may not want to overwrite asynchronously changing VCPU ev= ent >>>> states on write-back. So allow to skip nmi.pending and sipi_vector b= y >>>> setting corresponding bits in the flags field of kvm_vcpu_events. >>>> >>>> Signed-off-by: Jan Kiszka >>>> =20 >>> Can't you handle this in userspace entirely, only updating vcpu_event= s >>> state when appropriate? >>> =20 >> For what we do now I think you're right, it can be handled in userspac= e. >> >> But in general, there's currently no way to update vcpu_events without= =20 >> overwriting nmi and sipi_vector, which can also be written concurrentl= y =20 >> by other vcpus. So there's a hole in the interface. >> >>> Shouldnt the vcpu be stopped in the first place, when its state is >>> updated? >>> =20 >> It is stopped, but other vcpus are not. >=20 > I don't see the need for setting any state in kvm_vcpu_events > automatically, on kernel entry (apparently there was consensus that > saving similar state explicitly in qemu was the way to go). (I don't think so. IMHO the cleaner way is to avoid loading critical states unless we are resetting or vmloading.) >=20 > kvm_arch_put_registers in qemu saves mpstate now that way, > and the same problem is present. >=20 > The sites to load vcpu_events would be machine reset and cpu_load > only, right? That is how qemu use it, currently. But this interface should be designed with more flexibility. For the (yet theoretical) case you want to update RIP of a single VCPU, you also have to reset all the context-related states but maybe not the asynchronously changing ones like nmi.pending. We have no such use case yet, but KVM should not prevent them by design (if the change is so trivial). Jan --------------enig065955635672F736FE4F3094 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 iEYEARECAAYFAksewlUACgkQitSsb3rl5xSIHQCgpebx28JZlCNvjlAaAqiGlZ6z E+gAnjZUm5iiT2PrkuYtOkDpCo6IrSOD =isOQ -----END PGP SIGNATURE----- --------------enig065955635672F736FE4F3094--