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 15:12:40 +0100 Message-ID: <4B02AF58.4010407@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> <4B029FA8.5080205@web.de> <4B02A4FD.4010802@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC16108E90F5E8850292FA74A" Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:58210 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065AbZKQOMm (ORCPT ); Tue, 17 Nov 2009 09:12:42 -0500 In-Reply-To: <4B02A4FD.4010802@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC16108E90F5E8850292FA74A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 11/17/2009 03:05 PM, Jan Kiszka wrote: >> >>> Problem is, the inject channels are implied (APIC messages in smp >>> guests). Documentation is good, but if we can avoid it that's better= =2E >>> >>> Note the only way to rmw vcpu events during smp is pausing the guest,= >>> because of this race. >>> =20 >> That's what qemu does on reset and load. >> =20 >=20 > These aren't rmw. Not logically, but ATM technically. >=20 >> 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 whe= n >> doing a true reset. Back to square #1: we would still need the propose= d >> high-level interface to communicate the difference between replay and >> drop queue. >> =20 >=20 > There's no need for get+lock / put+unlock; a normal get/put with the You need to track when to queue and when to apply directly. Call it lock or call it something else. > addition that get flushes the queue suffices. To make sure queued > events don't affect set you need to stop the entire VM before setting > state, but you need to do that anyway for non-rmw writes. >=20 Well, sounds good, but it will be a non-trivial change in the interface semantics. At bare minimum, we would need a new mp_state interface. If we would count mp_state to our new event structure (hmm...), then we could confine the semantical changes to that new IOCTL pair. But how to deal with existing KVM kernels with their mp_state interface? It's a bit like the vcpu state thing: we are already down a specific road, and it's hard to turn around. Jan --------------enigC16108E90F5E8850292FA74A 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 iEYEARECAAYFAksCr10ACgkQitSsb3rl5xQ+3gCgtXj5Rwucz1kpsWXmowp2le5e nJoAoK6Vgf0OWTk5y3pGuMqE5Zzfk5hW =A86Q -----END PGP SIGNATURE----- --------------enigC16108E90F5E8850292FA74A--