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 12:27:26 +0300 Message-ID: <4A1BB5FE.9070300@redhat.com> References: <1242826497-6797-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <4A1A57D8.4070203@linux.vnet.ibm.com> <4A1BA106.6070600@redhat.com> <200905261031.12391.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Christian Ehrhardt , kvm@vger.kernel.org, cotte@de.ibm.com, heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com, Marcelo Tosatti To: =?ISO-8859-1?Q?Christian_Borntr=E4ger?= Return-path: Received: from mx2.redhat.com ([66.187.237.31]:48369 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754182AbZEZJ1a (ORCPT ); Tue, 26 May 2009 05:27:30 -0400 In-Reply-To: <200905261031.12391.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Borntr=E4ger wrote: > Am Dienstag 26 Mai 2009 09:57:58 schrieb Avi Kivity: > =20 >>> I could add that behaviour, but that could make our normal interrup= t >>> 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 se= t" >>> functionality and think about adding that in my loop. >>> =20 >> I don't understand why it would affect your interrupt handling. We = need >> =20 > > As far as I understand x86, every host interrupt causes a guest exit. > =20 Yes. > On s390 the SIE instruction is interruptible. On a host interrupt (li= ke an=20 > IPI) the host interrupt handler runs and finally jumps back into the= SIE=20 > instruction. The hardware will continue with guest execution. This h= as the=20 > advantage, that we dont have to load/save guest and host registers on= host=20 > interrupts. (the low level interrupt handler saves the registers of t= he=20 > interrupted context) > =20 Neat stuff. Wish I had something like that. > In our low-level interrupt handler we do check for signal_pending,=20 > machine_check_pending and need_resched to leave the sie instruction. = =46or=20 > anything else a the host sees a cpu bound guest always in the SIE ins= truction.=20 > =20 Okay, now I understand (and agree with) you multi-level kick thing. =20 Maybe we could do it like so: Interrupt handler (on s390 only) checks vcpu->requests, handles the one= s=20 it cans. If bits are still set, it exits to arch loop, which handles=20 the bits it cans. If bits are still set, it exits to the generic code=20 loop, which can finally exit to userspace. Does this fit with s390 hardware? --=20 error compiling committee.c: too many arguments to function