From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMzZ7-0003u6-SW for qemu-devel@nongnu.org; Thu, 07 Dec 2017 12:02:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMzZ2-0003wO-3i for qemu-devel@nongnu.org; Thu, 07 Dec 2017 12:02:29 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50164) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eMzZ1-0003vO-RB for qemu-devel@nongnu.org; Thu, 07 Dec 2017 12:02:24 -0500 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB7H18QL043723 for ; Thu, 7 Dec 2017 12:02:20 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2eq8m33kjt-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 07 Dec 2017 12:02:14 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Dec 2017 17:01:49 -0000 References: <20171128134648.21530-1-cohuck@redhat.com> <20171205085906.GA3894@lagrange> <20171207173418.7c70e5e9.cohuck@redhat.com> From: Halil Pasic Date: Thu, 7 Dec 2017 18:01:46 +0100 MIME-Version: 1.0 In-Reply-To: <20171207173418.7c70e5e9.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Message-Id: <786c5a2c-d61e-cfa1-c3b7-f36c69ec3a75@linux.vnet.ibm.com> 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: Cornelia Huck , Bjoern Walk Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org, borntraeger@de.ibm.com, pmorel@linux.vnet.ibm.com On 12/07/2017 05:34 PM, Cornelia Huck wrote: > On Tue, 5 Dec 2017 09:59:06 +0100 > Bjoern Walk wrote: > >> Cornelia Huck [2017-11-28, 02:46PM +0100]: >>> info qom-tree shows several devices under unattached that probably >>> should go somewhere. >>> >>> 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(+) >>> >>> -- >>> 2.13.6 >>> >>> >> >> Regarding the discussion about whether the QOM tree is API and what >> exploiters like libvirt should do, Halil asked me to chip in. >> >> This patch is fine from libvirt perspective. I did a quick smoke test >> and you can have a >> >> Tested-by: Bjoern Walk >> >> for what it's worth. > > Thanks for checking. > >> >> In general, I kind of agree with Halil. Unless somewhere in QEMU it is >> documented that the QOM tree is not guaranteed to be stable for >> exploiters, I'd consider is part of the API. libvirt does use at least >> some hardcoded paths, most of the time for CPUs in /machine/unattached, >> so if that relation would change, things break. However, there is also >> code to traverse the QOM tree recursively and find a path for a given >> type(?) name. If this is the preferred way, we probably should change >> this in libvirt to be safe. > > OK, with that in mind and as we're now adding a property to check on > the css bridge, I vote for including patch 1 now (having a fixed > location under /machine looks saner that having to > check /machine/unattached/device[], which might not be stable). > > Patch 2 needs more discussion, as I'm not sure whether what I'm doing > is the correct way to go about this (and other machines are in the same > situation). Not sure whether it is worth trying to attach the zpci > devices somewhere. > I think, if it's kind of API, then fixing sooner is better than fixing later. I also agree that patch 1 should be higher priority. Before we do patch 1 I would like having agreed and documented whether this is API or not. If we decide it's an API, I think we should consider deprecating the current interface, but keep it working for two releases or so. I think nothing speaks against introducing a link form unattached in patch 1 (but I have not tried yet). Halil