Re: [PATCH 7/8] qemuxmlconftest: Update memory-hotplug-virtio-mem-s390x.xml
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