From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJhhb-0005ge-NH for qemu-devel@nongnu.org; Tue, 28 Nov 2017 10:21:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJhhY-0005eX-IN for qemu-devel@nongnu.org; Tue, 28 Nov 2017 10:21:39 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:44176 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJhhY-0005eN-Bz for qemu-devel@nongnu.org; Tue, 28 Nov 2017 10:21:36 -0500 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASFD5JW079000 for ; Tue, 28 Nov 2017 10:21:33 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2eh9xmhq9r-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Nov 2017 10:21:32 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 28 Nov 2017 15:21:24 -0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vASFLL6o43843774 for ; Tue, 28 Nov 2017 15:21:21 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 91FA352FAD for ; Tue, 28 Nov 2017 14:14:43 +0000 (GMT) Received: from oc3836556865.ibm.com (unknown [9.152.224.205]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 7FD1C52FAE for ; Tue, 28 Nov 2017 14:14:43 +0000 (GMT) References: <20171128134648.21530-1-cohuck@redhat.com> <6513d1c5-032e-b9d0-3dab-f2d0bd337ae2@linux.vnet.ibm.com> <20171128152718.229a20fe.cohuck@redhat.com> From: Halil Pasic Date: Tue, 28 Nov 2017 16:21:20 +0100 MIME-Version: 1.0 In-Reply-To: <20171128152718.229a20fe.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Message-Id: Subject: Re: [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 11/28/2017 03:27 PM, Cornelia Huck wrote: > On Tue, 28 Nov 2017 15:17:38 +0100 > Halil Pasic wrote: > >> On 11/28/2017 02:46 PM, Cornelia Huck wrote: >>> info qom-tree shows several devices under unattached that probably >>> should go somewhere. >> >> I think this was reported by me. See >> MID: <76f95c6f-641e-2fe0-73b4-3ab24fc1a93f@linux.vnet.ibm.com> >> >> I would not mind a Reported-by: Halil Pasic . >> Or do you see this differently? > > Apparently I forgot to add it to the first one. Will do. np It's just that I've spent quite some time writing that email and identifying the oddities. > >> >> If these are bugs. I would prefer commit messages and titles reflecting >> this fact. > > I don't see this as fixing bugs, more removing oddities. > >> >> Otherwise at first glance both patches seem sane. > > Can I count this as an ack, or do you plan to do more review? > Yes I was planning to give it another look. And I do already have questions. Isn't the QOM composition tree API? I mean let's assume the QMP commands working on this tree are not completely useless. How is client code (management software) supposed to work, assumed it can rely on paths of e.g. properties being stable. Just imagine we had this default-cssid property (for the sake of the argument, not like we want it) on the css bridge. Now if the composition tree is API then these can only be bug fixes (IMHO). There are also other oddities I've spotted. My idea was to put this composition tree discussion on hold until the vfio-ccw stuff is sorted out. I would certainly like to build a better understanding. Halil >> >> Regards, >> Halil >> >>> >>> The css bridge should attach to the machine, as it has a similar >>> purpose as e.g. a pci host bridge. >>> >>> The autogenerated network devices should be in the same bucket as any >>> other device; I'm just not sure about the way I went about it. >>> >>> The zpci devices are still problematic: I don't have a good idea where >>> they should show up. >>> >>> Remaining in the unattached container are the sysbus, memory regions >>> and cpus. >>> >>> Cornelia Huck (2): >>> s390x/css: attach css bridge >>> s390x: attach autogenerated nics >>> >>> hw/s390x/css-bridge.c | 2 ++ >>> hw/s390x/s390-virtio-ccw.c | 2 ++ >>> 2 files changed, 4 insertions(+) >>> >> > >