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: Mon, 11 May 2009 16:15:27 +0300 Message-ID: <4A0824EF.5010201@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> 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]:51892 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752650AbZEKNPb (ORCPT ); Mon, 11 May 2009 09:15:31 -0400 In-Reply-To: <4A08217E.6000102@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Ehrhardt wrote: > >> On x86, we use slots_lock to protect memory slots. When we change >> the global memory configuration, we set a bit in vcpu->requests, and >> send an IPI to all cpus that are currently in guest mode for our >> guest. This forces the cpu back to host mode. On the next entry, >> vcpu_run notices vcpu->requests has the bit set and reloads the mmu >> configuration. Of course, all this may be overkill for s390. >> > I thought about implementing it with slots_lock, vcpu->request, etc > but it really looks like overkill for s390. We could make (some of) it common code, so it won't look so bad. There's value in having all kvm ports do things similarly; though of course we shouldn't force the solution when it isn't really needed. vcpu->requests is useful whenever we modify global VM state that needs to be seen by all vcpus in host mode; see kvm_reload_remote_mmus(). > At least today we can assume that we only have one memslot. Therefore > a set_memslot with already created vcpu's will still not interfere > with running vcpus (they can't run without memslot and since we have > only one they won't run). > Anyway I the code is prepared to "meet" running vcpus, because it > might be different in future. To prevent the livelock issue I changed > the code using mutex_trylock and in case I can't get the lock I > explicitly let the vcpu exit from guest. Why not do it unconditionally? -- error compiling committee.c: too many arguments to function