From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state Date: Tue, 17 Nov 2009 10:16:51 +0100 Message-ID: <4B026A03.4080600@web.de> References: <4B018542.3020602@siemens.com> <4B01A487.3020808@redhat.com> <4B01C2B0.3000205@web.de> <4B02592C.6060004@redhat.com> <4B025B50.4070505@web.de> <4B0260D7.1060107@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB5F08461B496EA8F643FAFC" Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:33701 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752386AbZKQJQz (ORCPT ); Tue, 17 Nov 2009 04:16:55 -0500 In-Reply-To: <4B0260D7.1060107@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB5F08461B496EA8F643FAFC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 11/17/2009 10:14 AM, Jan Kiszka wrote: >> >> >>> state that is updated outside the vcpu thread. These are particularl= y >>> bad since we can't exclude them from updates without excluding other >>> state as well. >>> =20 >> We easily can, using the very same mechanism: No need to overwrite any= >> of the kvm_vcpu_events during runtime, only on reset/vmload). >> =20 >=20 > That's because qemu has no need for this. But kvm is more than just > serving qemu, we try to be more general. That said, I can't really see= > anyone wanting to arbitrarily inject an exception. Well, the current API comes with millions of ways to shoot yourself into the foot. I don't think we can avoid them all. >=20 >>> The whole issue is tricky. I'm inclined to pretend we never meant an= y >>> vcpu state (outside lapic) to be asynchronous and declare the whole >>> thing a bug. We could fix it by modeling external changes to state >>> (INIT, SIPI, NMI) as messages queued to the vcpu, to be processed in = the >>> vcpu thread. The queue would be drained before running the vcpu or >>> before reading state from userspace, so the message queue contents ca= n >>> never be observed and never lost. >>> >>> Of course, we can't really implement this as a queue (SIGSTOP vcpu >>> thread -> overflow), but a word is sufficient. INIT writes the word= , >>> everything else uses compare-and-swap or set_bit to raise events (e.g= =2E >>> SIPI =3D do { oldq =3D vcpu->queue; newq =3D (oldq& ~SIPI_MASK) | si= pi_vector >>> | RUNNING; } while (!cas(&vcpu->queue, oldq, newq))) >>> >>> =20 >> I do not yet see why we need this complication, why the proposed model= >> isn't enough. >> =20 >=20 > The current interface is subtly dangerous, you can't run set(get()) as > you would expect. >=20 > (well you can't with the lapic or the tsc msr either...) >=20 We may start documenting such dependency in kvm/api.txt. On the other hand, if you have a get/set interface vs. an inject channel, I think it's obvious that one can overwrite the other. Jan --------------enigEB5F08461B496EA8F643FAFC 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 iEYEARECAAYFAksCagoACgkQitSsb3rl5xRxsACgujJopa4miVAMn8UamObkL8ix X6IAoOPZhqzW+JjDyWUjd6z3qr1pNtt6 =cf7y -----END PGP SIGNATURE----- --------------enigEB5F08461B496EA8F643FAFC--