Re: [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Mon, 21 Nov 2016 23:12:04 -0200
Eduardo Habkost <ehabkost@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.