From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [PATCH 3/3] kvm-s390: streamline memslot handling Date: Tue, 26 May 2009 12:31:17 +0200 Message-ID: <4A1BC4F5.1080603@linux.vnet.ibm.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> <4A1BB5FE.9070300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-1?Q?Christian_Borntr=E4ger?= , kvm@vger.kernel.org, cotte@de.ibm.com, heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com, Marcelo Tosatti To: Avi Kivity Return-path: Received: from mtagate7.de.ibm.com ([195.212.29.156]:39266 "EHLO mtagate7.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbZEZKbX (ORCPT ); Tue, 26 May 2009 06:31:23 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.14.3/8.13.8) with ESMTP id n4QAVMWg196346 for ; Tue, 26 May 2009 10:31:22 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4QAVMJ13326184 for ; Tue, 26 May 2009 12:31:22 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4QAVLjg000587 for ; Tue, 26 May 2009 12:31:22 +0200 In-Reply-To: <4A1BB5FE.9070300@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Christian Borntr=E4ger wrote: >> Am Dienstag 26 Mai 2009 09:57:58 schrieb Avi Kivity: >> =20 [...] >> In our low-level interrupt handler we do check for signal_pending,=20 >> machine_check_pending and need_resched to leave the sie instruction.= =20 >> For anything else a the host sees a cpu bound guest always in the SI= E=20 >> instruction. =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=20 > ones it cans. If bits are still set, it exits to arch loop, which=20 > handles the bits it cans. If bits are still set, it exits to the=20 > generic code loop, which can finally exit to userspace. > > Does this fit with s390 hardware? > I like this idea instead of explicitly kicking to an (upper) level to=20 use the lowest kick and exit if not able to handle. I think it should work (no guarantee) and I try to come up with=20 something in the next few days - either a updated patch series or=20 additional discussion input :-). --=20 Gr=FCsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization=20