From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXuXh-000325-Qg for qemu-devel@nongnu.org; Wed, 09 Apr 2014 11:36:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXuXZ-0001H3-VG for qemu-devel@nongnu.org; Wed, 09 Apr 2014 11:36:01 -0400 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:38640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXuXZ-0001Gg-Fz for qemu-devel@nongnu.org; Wed, 09 Apr 2014 11:35:53 -0400 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 9 Apr 2014 16:35:52 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1FB2417D8047 for ; Wed, 9 Apr 2014 16:36:43 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s39FZht219529896 for ; Wed, 9 Apr 2014 15:35:43 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s39FZfix012142 for ; Wed, 9 Apr 2014 09:35:42 -0600 Date: Wed, 9 Apr 2014 17:35:38 +0200 From: Cornelia Huck Message-ID: <20140409173538.14a95333.cornelia.huck@de.ibm.com> In-Reply-To: <53455989.3060407@suse.de> References: <1397043298-25755-1-git-send-email-cornelia.huck@de.ibm.com> <1397043298-25755-4-git-send-email-cornelia.huck@de.ibm.com> <5345538C.9060709@suse.de> <20140409162401.072f887c.cornelia.huck@de.ibm.com> <53455989.3060407@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 3/5] s390x: Add I/O adapter registration. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: gleb@kernel.org, borntraeger@de.ibm.com, qemu-devel@nongnu.org, pbonzini@redhat.com On Wed, 09 Apr 2014 16:30:33 +0200 Alexander Graf wrote: > > On 09.04.14 16:24, Cornelia Huck wrote: > > On Wed, 09 Apr 2014 16:05:00 +0200 > > Alexander Graf wrote: > > > >> On 09.04.14 13:34, Cornelia Huck wrote: > >>> Register an I/O adapter interrupt source for when virtio-ccw devices start > >>> using adapter interrupts. > >>> > >>> Reviewed-by: Thomas Huth > >>> Signed-off-by: Cornelia Huck > >>> --- > >>> hw/intc/s390_flic.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++ > >>> hw/s390x/css.c | 51 ++++++++++++++++++++++++++++++++++++++++++ > >>> hw/s390x/css.h | 4 ++++ > >>> hw/s390x/virtio-ccw.c | 4 ++++ > >>> hw/s390x/virtio-ccw.h | 1 + > >>> target-s390x/cpu.h | 33 +++++++++++++++++++++++++++ > >>> 6 files changed, 152 insertions(+) > >>> > >>> diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c > >>> index 2bf0af8..1193682 100644 > >>> --- a/hw/s390x/virtio-ccw.c > >>> +++ b/hw/s390x/virtio-ccw.c > >>> @@ -522,6 +522,10 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw) > >>> dev->thinint_isc = thinint->isc; > >>> dev->ind_bit = thinint->ind_bit; > >>> cpu_physical_memory_unmap(thinint, hw_len, 0, hw_len); > >>> + ret = css_register_io_adapter(CSS_IO_ADAPTER_VIRTIO, > >>> + dev->thinint_isc, true, false, > >>> + &dev->adapter_id); > >> In all other machines the machine file is the one creating the link > >> between a device and the interrupt controller. Can we do something > >> similar for s390? > > Hm. This would imply we'd need to add a virtio I/O adapter for each isc > > (0-7) at startup, regardless whether the guest enables adapter > > interrupts on any of those iscs. Moreover, we'd need to do the same for > > each type (on each isc) if we add more types of I/O adapters later > > (should we want to support one of the other adapter-interrupt using > > devices). I'd prefer to add an I/O adapter only when needed. > > I'm not sure I can follow you here. Instead of registering the interrupt > vector on the fly, you would still register it on the fly, but after the > virtio-ccw device got created, no? You mean register-at-device-creation instead of register-while-interpreting-ccw? We'd end up with the same problem: We don't know which isc the guest wants to use for adapter interrupts at that point in time, so we would need to register for all iscs. I don't think that is what we want.