From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/3] kvm-s390: streamline memslot handling Date: Tue, 26 May 2009 10:57:58 +0300 Message-ID: <4A1BA106.6070600@redhat.com> References: <1242826497-6797-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1242826497-6797-4-git-send-email-ehrhardt@linux.vnet.ibm.com> <4A195C0E.3000900@redhat.com> <4A1A57D8.4070203@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, borntraeger@de.ibm.com, cotte@de.ibm.com, heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com, Marcelo Tosatti To: Christian Ehrhardt Return-path: Received: from mx2.redhat.com ([66.187.237.31]:51425 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347AbZEZH6D (ORCPT ); Tue, 26 May 2009 03:58:03 -0400 In-Reply-To: <4A1A57D8.4070203@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Ehrhardt wrote: >> >> There already exists a loop which does this, see >> make_all_cpus_request(). It uses an IPI (Marcelo, can't it use the >> reschedule interrupt?). It has a couple of optimizations -- if the >> request is already set, it skips the IPI, and it avoids the IPI for >> vcpus out of guest mode. Maybe it could fit s390 too. > I assume that the IPI on x86 is a implicit consequence of the > smp_call_function_many function, Yes. It's only used to exit the guest, the IPI itself does nothing. > but I think this doesn't work that way for us. The kick implied by > that call would be recieved, but not reach the code the checke > vcpu->request. vcpu->requests is not checked by the IPI. Instead, it is checked just before entering guest mode, with interrupts disabled. If the request is made before the check, no IPI is made, and the check finds the bit set. If the request is made after the check, an IPI is made, and the guest exits immediately after entry. > I could add that behaviour, but that could make our normal interrupt > handling much slower. Therefore I don't want to call that function, > but on the other hand I like the "skip if the request is already set" > functionality and think about adding that in my loop. I don't understand why it would affect your interrupt handling. We need someone that talks both x86 and s390 to break the language barrier... I'll apply the patches, but please do look further into increasing commonality. -- error compiling committee.c: too many arguments to function