From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2] KVM: x86: Convert INIT and SIPI signals into synchronously handled requests Date: Wed, 06 Mar 2013 22:58:12 +0100 Message-ID: <5137BBF4.9040004@web.de> References: <70318159.3047162.1362550372481.JavaMail.root@redhat.com> <5136F702.4070101@web.de> <20130306213020.GB23299@amt.cnet> <5137B78F.8020009@web.de> <20130306215027.GA25030@amt.cnet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NNKCOOTOJRUMTTOIHIWP" Cc: Paolo Bonzini , Gleb Natapov , kvm To: Marcelo Tosatti Return-path: Received: from mout.web.de ([212.227.17.11]:59934 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752611Ab3CFV6P (ORCPT ); Wed, 6 Mar 2013 16:58:15 -0500 In-Reply-To: <20130306215027.GA25030@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NNKCOOTOJRUMTTOIHIWP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-03-06 22:50, Marcelo Tosatti wrote: > On Wed, Mar 06, 2013 at 10:39:27PM +0100, Jan Kiszka wrote: >> On 2013-03-06 22:30, Marcelo Tosatti wrote: >>> On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote: >>>> On 2013-03-06 07:12, Paolo Bonzini wrote: >>>>> >>>>>> On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote: >>>>>>> On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote: >>>>>>>> From: Jan Kiszka >>>>>>>> >>>>>>>> A VCPU sending INIT or SIPI to some other VCPU races for setting= >>>>>>>> the >>>>>>>> remote VCPU's mp_state. When we were unlucky, >>>>>>>> KVM_MP_STATE_INIT_RECEIVED >>>>>>>> was overwritten by kvm_emulate_halt and, thus, got lost. >>>>>>>> >>>>>>>> Fix this by raising requests on the sender side that will then b= e >>>>>>>> handled synchronously over the target VCPU context. >>>>>>>> >>>>>>>> Signed-off-by: Jan Kiszka >>>>>>> >>>>>>> Why is kvm_emulate_halt being executed from >>>>>>> KVM_MP_STATE_INIT_RECEIVED/KVM_MP_STATE_SIPI_RECEIVED again? >>>>>>> >>>>>>> Why is it not true that the only valid transition from >>>>>>> KVM_MP_STATE_HALTED is from KVM_MP_STATE_RUNNABLE? >>>>>> >>>>>> See Paolo's table, it is. So why fix a race which should not be >>>>>> happening in the first place. >>>>> >>>>> The bad transition happens exactly because of the race. >>>>> Are you saying you prefer the solution with cmpxchg? >>>> >>>> I think we are past that point in our discussion and should really >>>> separate signal (INIT/SIPI) from state (INIT/SIPI_RECEIVED etc.). >>>> >>>> Jan >>> >>> The sentence "KVM_MP_STATE_INIT_RECEIVED overwritten by >>> kvm_emulate_halt" is contradictory, unless i miss something. >> >> http://thread.gmane.org/gmane.comp.emulators.kvm.devel/105638 >> >> Jan >=20 > "A VCPU sending INIT or SIPI to some other VCPU races for setting the > remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVE= D > was overwritten by kvm_emulate_halt and, thus, got lost. >=20 >=20 > Fix this by raising requests on the sender side that will then be > handled synchronously over the target VCPU context." >=20 >=20 > The scenario you describe is: >=20 > vcpu0,bsp vcpu1 >=20 > vcpu0->mp_state=3DKVM_MP_STATE_RUNNABLE This is not related to the race. > vcpu1->mp_state=3DKVM_MP_STATE_UNINIT Nor this. >=20 > at __accept_apic_irq() > vcpu1->mp_state=3DKVM_MP_STATE_INIT_RECEIVED > kvm_emulate_halt > vcpu1->mp_state=3D > KVM_MP_STATE_HALTED Just these two sequences. vcpu0 need not be the BSP, any VCPU can send INIT at any time. >=20 >=20 > This is what the first sentence from the patch refers to, correct? The last part, yes. But there are more races due to the unsynchronized access to mp_state in lapic.c. I'm going to refactor my patch according to Gleb's and Paolos's suggestions, trying to keep the signals lapic-local, adding services to check for them and translate them into mp_state transitions over the target vcpu context. Jan ------enig2NNKCOOTOJRUMTTOIHIWP 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.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3u/QACgkQitSsb3rl5xSLkgCfUpeKcstSiAJa3iFbzp0kgvxV fKkAoJVL1CAFDGFnireib76sbNitd5ak =rHS0 -----END PGP SIGNATURE----- ------enig2NNKCOOTOJRUMTTOIHIWP--