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 17:58:29 +0100 Message-ID: <4B02D635.6070805@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> <4B02AF58.4010407@web.de> <4B02B252.5080207@redhat.com> <4B02D444.6080402@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F5872ACB47C0D524BCA0C15" Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:52444 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755203AbZKQQ64 (ORCPT ); Tue, 17 Nov 2009 11:58:56 -0500 In-Reply-To: <4B02D444.6080402@web.de> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F5872ACB47C0D524BCA0C15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Avi Kivity wrote: >> On 11/17/2009 04:12 PM, Jan Kiszka wrote: >>>>> The alternative would be a complex get&lock/put&unlock + a queue fo= r >>>>> 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 prop= osed >>>>> high-level interface to communicate the difference between replay a= nd >>>>> drop queue. >>>>> =20 >>>>> =20 >>>> There's no need for get+lock / put+unlock; a normal get/put with the= >>>> =20 >>> You need to track when to queue and when to apply directly. Call it l= ock >>> or call it something else. >>> =20 >> You always queue. When starting vcpu_run() or reading state to >> userspace you flush the queue. >=20 > Now I finally got your idea. >=20 >> The hardware equivalent is posting APIC messages, and the core executi= ng >> them. >> >>>> addition that get flushes the queue suffices. To make sure queued >>>> events don't affect set you need to stop the entire VM before settin= g >>>> 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 interfa= ce >>> semantics. At bare minimum, we would need a new mp_state interface. I= f >>> 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 i= t's >>> hard to turn around. >>> =20 >> I think we're not on the same page here. As I see it, no interface >> change is needed at all. >> >> It's true that existing kernels don't handle this properly, which is w= hy >> I said I'm willing to treat it as a bug (and thus the -stable treatmen= t >> etc.). I admit it's a stretch since this is not going to be trivial >> (though I think less complex that you believe). >> >> Putting mp_state into the events structure is reasonable regardless of= >> this issue (and doable since we haven't pushed it to 2.6.33 yet). But= I >> want to understand why you think it's needed. >> >=20 > That wouldn't be required anymore with the "always queue" policy. Hmm, unless we need mp_state manipulation analogously to KVM_NMI vs. KVM_SET_VCPU_STATE: The former will queue, the latter write, but may be overwritten by anything queued. If you just queue KVM_SET_MP_STATE, you still have a conflict between concurrent manipulations from user space, something we want to resolve automagically. >=20 > But what would you queue at all? Only mp_state, nmi_pending and > sipi_vector? Or also all the relevant PIC and LAPIC states that might b= e > changed asynchronously? >=20 Jan --------------enig8F5872ACB47C0D524BCA0C15 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 iEYEARECAAYFAksC1jYACgkQitSsb3rl5xSilgCfbGZaA1MSQ11dikTlS8dvYJGV OScAn3PwaCXCMhKqZ6U9dfhuwHjTMRcv =DizR -----END PGP SIGNATURE----- --------------enig8F5872ACB47C0D524BCA0C15--