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 14:05:44 +0100 Message-ID: <4B029FA8.5080205@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> <4B026A03.4080600@web.de> <4B0298F0.3080007@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41CBA7572034B04CB73FAE26" Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:57986 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbZKQNFq (ORCPT ); Tue, 17 Nov 2009 08:05:46 -0500 In-Reply-To: <4B0298F0.3080007@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41CBA7572034B04CB73FAE26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 11/17/2009 11:16 AM, Jan Kiszka wrote: >> >>> 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 s= ee >>> anyone wanting to arbitrarily inject an exception. >>> =20 >> Well, the current API comes with millions of ways to shoot yourself in= to >> the foot. I don't think we can avoid them all. >> =20 >=20 > It would be nice to make the API saner. Do you know of more holes? >=20 >>> The current interface is subtly dangerous, you can't run set(get()) a= s >>> you would expect. >>> >>> (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. >> =20 >=20 > Problem is, the inject channels are implied (APIC messages in smp > guests). Documentation is good, but if we can avoid it that's better. >=20 > Note the only way to rmw vcpu events during smp is pausing the guest, > because of this race. That's what qemu does on reset and load. The alternative would be a complex get&lock/put&unlock + a queue for async events during the lock + an option to ignore what was queued when doing a true reset. Back to square #1: we would still need the proposed high-level interface to communicate the difference between replay and drop queue. Jan --------------enig41CBA7572034B04CB73FAE26 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 iEYEARECAAYFAksCn60ACgkQitSsb3rl5xS7fQCgrGZ4O80K9naYBhzVIZpoxvdE 7iMAoOFYREil9jNx9V9BvFd2f1cEqfUa =aVrM -----END PGP SIGNATURE----- --------------enig41CBA7572034B04CB73FAE26--