From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/6] kvm-s390: Fix memory slot versus run Date: Tue, 12 May 2009 14:35:06 +0300 Message-ID: <4A095EEA.60902@redhat.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> <4A093E1B.9030008@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Christian Borntraeger , Carsten Otte To: Christian Ehrhardt Return-path: Received: from mx2.redhat.com ([66.187.237.31]:32970 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751457AbZELLfK (ORCPT ); Tue, 12 May 2009 07:35:10 -0400 In-Reply-To: <4A093E1B.9030008@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Ehrhardt wrote: > Avi Kivity wrote: >> Christian Ehrhardt wrote: >>> >>> The bad thing on vcpu->request in that case is that I don't want the >>> async behaviour of vcpu->requests in that case, I want the memory >>> slot updated in all vcpu's when the ioctl is returning. >> >> You mean, the hardware can access the vcpu control block even when >> the vcpu is not running? > No, hardware only uses it with a running vcpu, but I realised my own > fault while changing the code to vcpu->request style. > For s390 I need to update the KVM->arch and *all* > vcpu->arch->sie_block... data synchronously. Out of interest, can you explain why? > 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 > should 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 running. > Until we ever support multiple slots, or updates of the existing > single 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) > it should be fair to aquire the lock with mutex_trylock and return > -EINVAL if we did not get all locks. OK. -- error compiling committee.c: too many arguments to function