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 18:01:32 +0300 Message-ID: <4A083DCC.8000805@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> 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]:53932 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753834AbZEKPBf (ORCPT ); Mon, 11 May 2009 11:01:35 -0400 In-Reply-To: <4A083956.2000200@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? > Looking at vcpu->request based solution I don't find the > synchronization I need. The changes to > vcpu->arch.guest_origin/guest_memsize and the changes to > vcpu->arch.sie_block->gmsor/gmslm need to happen without the vcpu > running. > Therefor i want the vcpu lock _before_ I update the both structs, > otherwise it could be racy (at least on s390). > > On the other hand while it is very++ unlikely to happen you are still > right that it could theoretically livelock there. > I might use vcpu->request in to not enter vcpu run again after such a > "kick" out of guest state. > It would be checked on vcpu_run enter and could then drop the lock, > call schedule, relock and check the flag again until it is cleared. > I'm not yet happy with this solution as I expect it to end up in > something like a reference count which then would not fit into the > existing vcpu->request flags :-/ > > As I mentioned above the changes to vcpu->arch and > vcpu->arch->sie_block have to be exclusive with the vcpu not running. > If I would find something as "transport" for the information I have on > set_memory_slot (origin/size) until the next vcpu_run entry I could do > both changes there synchronously. The information can be found in kvm->memslots. > In that case I could really use your suggested solution with > vcpu->request, kick out unconditionally and set values on next > (re-)entry. > > Hmmm .. Maybe I can find all I need on reentry in vcpu->kvm->memslots[]. Err... > 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 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 you use memslots. -- error compiling committee.c: too many arguments to function