On 1/27/25 13:44, David Hildenbrand wrote: > On 27.01.25 13:01, Boris Fiuczynski wrote: >> On 1/24/25 13:35, David Hildenbrand wrote: >>> On 24.01.25 13:21, Michal Privoznik wrote: >>>> Drop explicit request to place virtio-mem on PCI bus from the >>>> input memory-hotplug-virtio-mem-s390x.xml and demonstrate how the >>>> device is automatically placed onto CCW. >>>> >>> >>> Could it still be manually placed on the PCI bus? It can, but as you point out, qemu refuses to start. >>> >>> As of now, virtio-mem-pci is not supported on s390x -- IIRC plugging the >>> device would fail -- but maybe, in a distant future it might be >>> supported. >>> >> >> David, > > Hi Boris, > >> the libvirt probing of capabilities with qemu v9.2.0-1203-gd6430c17d7 >> returns virtio-mem-pci support based on the QOM. Should that be fixed? > > Right, it's similar to virtio-balloon-pci: while it is compiled into > QEMU, plugging these devices will fail due to lack of MSI-X support. [1] > > For virtio-mem-pci, in addition to MSI-X support, we'll have to wire up > the (un)plug handlers in the machine, which are currently blocked: > > Which leaves us with three options: > > (1) Leave it as is: device is compiled in but cannot be used, just like > virtio-balloon-pci > (2) Implement MSI-X and (un)plug support > (3) Do not compile the device in This last option is something I've experimented with, but then got lost in the weeds of code interdeps. In the end I've decided it's not a huge problem, is it. In my patches (e.g. 5/8) I look what bus is virtio-mem attached to and check for corresponding capability. OTOH, support for .prealloc and .dynamic-memslots is detected from virtio-mem-pci device. If virtio-mem-pci device would be compiled out then libvirt would need a code to check these attributes for virtio-mem-ccw. Michal
