From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9xxY-0001AH-2B for qemu-devel@nongnu.org; Thu, 24 Nov 2016 12:37:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9xxT-0008TX-6F for qemu-devel@nongnu.org; Thu, 24 Nov 2016 12:37:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58162) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9xxS-0008T5-U4 for qemu-devel@nongnu.org; Thu, 24 Nov 2016 12:37:15 -0500 Date: Thu, 24 Nov 2016 15:37:11 -0200 From: Eduardo Habkost Message-ID: <20161124173711.GI21830@thinpad.lan.raisama.net> References: <1479777133-23567-1-git-send-email-ehabkost@redhat.com> <1479777133-23567-7-git-send-email-ehabkost@redhat.com> <20161124174820.015135cb.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161124174820.015135cb.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: qemu-devel@nongnu.org, Markus Armbruster , Marcel Apfelbaum , "Michael S. Tsirkin" On Thu, Nov 24, 2016 at 05:48:20PM +0100, Cornelia Huck wrote: > On Mon, 21 Nov 2016 23:12:04 -0200 > Eduardo Habkost wrote: > > > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c > > index 24fae16..74b8fef 100644 > > --- a/hw/pci/pci.c > > +++ b/hw/pci/pci.c > > @@ -152,6 +152,7 @@ static void pci_bus_class_init(ObjectClass *klass, void *data) > > k->realize = pci_bus_realize; > > k->unrealize = pci_bus_unrealize; > > k->reset = pcibus_reset; > > + k->device_type = TYPE_PCI_DEVICE; > > This covers pci-per-se... > > > > > pbc->is_root = pcibus_is_root; > > pbc->bus_num = pcibus_num; > > > diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c > > index 9a7f7ee..8a6c1ae 100644 > > --- a/hw/s390x/css-bridge.c > > +++ b/hw/s390x/css-bridge.c > > @@ -17,6 +17,7 @@ > > #include "hw/s390x/css.h" > > #include "ccw-device.h" > > #include "hw/s390x/css-bridge.h" > > +#include "hw/s390x/virtio-ccw.h" > > > > /* > > * Invoke device-specific unplug handler, disable the subchannel > > @@ -81,6 +82,7 @@ static void virtual_css_bus_class_init(ObjectClass *klass, void *data) > > > > k->reset = virtual_css_bus_reset; > > k->get_dev_path = virtual_css_bus_get_dev_path; > > + k->device_type = TYPE_VIRTIO_CCW_DEVICE; > > ...this covers virtio-ccw... (notably _not_ generic css) > > > } > > > > static const TypeInfo virtual_css_bus_info = { > > > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c > > index 63f6248..7470fdd 100644 > > --- a/hw/s390x/s390-pci-bus.c > > +++ b/hw/s390x/s390-pci-bus.c > > @@ -783,10 +783,17 @@ static const TypeInfo s390_pcihost_info = { > > } > > }; > > > > +static void s390_pcibus_class_init(ObjectClass *oc, void *opaque) > > +{ > > + BusClass *bc = BUS_CLASS(oc); > > + bc->device_type = TYPE_S390_PCI_DEVICE; > > ...this covers zpci, which is needed _in addition to_ normal pci to make pci work on s390... > > > +} > > + > > static const TypeInfo s390_pcibus_info = { > > .name = TYPE_S390_PCI_BUS, > > .parent = TYPE_BUS, > > .instance_size = sizeof(S390PCIBus), > > + .class_init = s390_pcibus_class_init, > > }; > > > > static uint16_t s390_pci_generate_uid(void) > > > diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c > > index d6c0c72..815f3dd 100644 > > --- a/hw/virtio/virtio-bus.c > > +++ b/hw/virtio/virtio-bus.c > > @@ -293,6 +293,7 @@ static void virtio_bus_class_init(ObjectClass *klass, void *data) > > BusClass *bus_class = BUS_CLASS(klass); > > bus_class->get_dev_path = virtio_bus_get_dev_path; > > bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path; > > + bus_class->device_type = TYPE_VIRTIO_DEVICE; > > } > > > > static const TypeInfo virtio_bus_info = { > > ...and this covers virtio, which is kind of a glue bus. > > So on s390, we have the following: > > - to get virtio-ccw, we need virtio-ccw _and_ virtio > - to get virtio-pci, we need pci _and_ zpci _and_ virtio > - to get virtio-per-se, we need one of the combinations above > > Please stop me if I'm babbling, but there seem to be some > interdependencies which are different on different architectures and > I'm not sure how these should be modelled. This series doesn't cover any of the interdependencies between the multiple bus classes inside a machine. It just reports which device types are available for usage with "-device" or device_adde when running that machine-type. If the user is not supposed to plug devices directly to some of those buses, we can simply hide them on query-machines. (But we should still set BusClass::device_type to allow internal validation of the devices that are plugged on those bus objects). -- Eduardo