Re: [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices

[Bjoern Walk <bwalk@linux.vnet.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Cornelia Huck <cohuck@redhat.com> [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 <bwalk@linux.vnet.ibm.com>

for what it's worth.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 906 bytes --]