From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run Date: Tue, 12 May 2009 11:15:07 +0200 Message-ID: <4A093E1B.9030008@linux.vnet.ibm.com> References: <1241534358-32172-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1241534358-32172-2-git-send-email-ehrhardt@linux.vnet.ibm.com> <4A017C2E.6060306@redhat.com> <4A08217E.6000102@linux.vnet.ibm.com> <4A0824EF.5010201@redhat.com> <4A082C4E.60501@linux.vnet.ibm.com> <4A082FF3.4060908@redhat.com> <4A083956.2000200@linux.vnet.ibm.com> <4A083DCC.8000805@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, Christian Borntraeger , Carsten Otte To: Avi Kivity Return-path: Received: from mtagate5.de.ibm.com ([195.212.29.154]:36721 "EHLO mtagate5.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751013AbZELJPM (ORCPT ); Tue, 12 May 2009 05:15:12 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.14.3/8.13.8) with ESMTP id n4C9FBYr325132 for ; Tue, 12 May 2009 09:15:11 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4C9FBG83768520 for ; Tue, 12 May 2009 11:15:11 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4C9FBU7018417 for ; Tue, 12 May 2009 11:15:11 +0200 In-Reply-To: <4A083DCC.8000805@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Christian Ehrhardt wrote: >> >> The bad thing on vcpu->request in that case is that I don't want the= =20 >> async behaviour of vcpu->requests in that case, I want the memory=20 >> slot updated in all vcpu's when the ioctl is returning. > > You mean, the hardware can access the vcpu control block even when th= e=20 > vcpu is not running?=20 No, hardware only uses it with a running vcpu, but I realised my own=20 fault while changing the code to vcpu->request style. =46or s390 I need to update the KVM->arch and *all*=20 vcpu->arch->sie_block... data synchronously. That makes the "per vcpu resync on next entry" approach not feasible. On the other hand I realized at the same moment that the livelock shoul= d=20 be no issue for us, because as I mentioned: a) only one memslot b) a vcpu can't run without memslot So I don't even need to kick out vcpu's, they just should not be runnin= g. Until we ever support multiple slots, or updates of the existing single= =20 slot this should be ok, so is the bugfix patch this should be. To avoid a theoretical deadlock in case other code is changing (badly)=20 it should be fair to aquire the lock with mutex_trylock and return=20 -EINVAL if we did not get all locks. [...] >> If I can change it that way it will definitely require some testing. >> ... to be continued :-) > > I definitely recommend it -- would bring s390 more in line with the=20 > other ports (I know it's a backward step for you :) > > Note our plan is to change slots_lock to RCU, so it's even better if=20 > you use memslots. As long as we have the special conditions mentioned above I think its o= k=20 to implement it the way I do it now. I agree that if we ever support multiple memslots we should strive for = a=20 common solution. p.s. the second patch in the series ensures that a vcpu really never=20 runs without a memslot being set as this was another bug we had. --=20 Gr=C3=BCsse / regards,=20 Christian Ehrhardt IBM Linux Technology Center, Open Virtualization