On Thu, Nov 24, 2016 at 05:48:20PM +0100, Cornelia Huck wrote:
> On Mon, 21 Nov 2016 23:12:04 -0200
> Eduardo Habkost <ehabk...@redhat.com> wrote:
>
> <s390 glasses on>
>
> > 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
