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.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
...ory-hotplug-virtio-mem-s390x.s390x-latest.args | 6 ++----
...mory-hotplug-virtio-mem-s390x.s390x-latest.xml | 15 ++-------------
.../memory-hotplug-virtio-mem-s390x.xml | 2 --
3 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.args b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.args
index 9704d7d5e9..a6bbef5ce7 100644
--- a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.args
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.args
@@ -27,12 +27,10 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.config \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
--device '{"driver":"zpci","uid":1,"fid":0,"target":"pci.1","id":"zpci1"}' \
--device '{"driver":"pci-bridge","chassis_nr":1,"id":"pci.1","bus":"pci.0","addr":"0x1"}' \
-object '{"qom-type":"memory-backend-ram","id":"memvirtiomem0","reserve":false,"size":1073741824}' \
--device '{"driver":"virtio-mem-pci","node":0,"block-size":2097152,"requested-size":536870912,"memdev":"memvirtiomem0","id":"virtiomem0","bus":"pci.0","addr":"0x2"}' \
+-device '{"driver":"virtio-mem-ccw","node":0,"block-size":2097152,"requested-size":536870912,"memdev":"memvirtiomem0","id":"virtiomem0","devno":"fe.0.0002"}' \
-object '{"qom-type":"memory-backend-file","id":"memvirtiomem1","mem-path":"/dev/hugepages2M/libvirt/qemu/-1-QEMUGuest1","reserve":false,"size":2147483648,"host-nodes":[1,2,3],"policy":"bind"}' \
--device '{"driver":"virtio-mem-pci","node":0,"block-size":2097152,"requested-size":1073741824,"memdev":"memvirtiomem1","prealloc":true,"memaddr":5637144576,"dynamic-memslots":true,"id":"virtiomem1","bus":"pci.1","addr":"0x1"}' \
+-device '{"driver":"virtio-mem-ccw","node":0,"block-size":2097152,"requested-size":1073741824,"memdev":"memvirtiomem1","prealloc":true,"memaddr":5637144576,"dynamic-memslots":true,"id":"virtiomem1","devno":"fe.0.0003"}' \
-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","read-only":false}' \
-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-1-storage","id":"virtio-disk0","bootindex":1}' \
-audiodev '{"id":"audio1","driver":"none"}' \
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.xml b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.xml
index 336c6e5aac..fe18b1ec7b 100644
--- a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.xml
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.s390x-latest.xml
@@ -28,13 +28,6 @@
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
</disk>
<controller type='pci' index='0' model='pci-root'/>
- <controller type='pci' index='1' model='pci-bridge'>
- <model name='pci-bridge'/>
- <target chassisNr='1'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'>
- <zpci uid='0x0001' fid='0x00000000'/>
- </address>
- </controller>
<audio id='1' type='none'/>
<memballoon model='virtio'>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
@@ -47,9 +40,7 @@
<block unit='KiB'>2048</block>
<requested unit='KiB'>524288</requested>
</target>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'>
- <zpci uid='0x0002' fid='0x00000001'/>
- </address>
+ <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/>
</memory>
<memory model='virtio-mem'>
<source>
@@ -63,9 +54,7 @@
<requested unit='KiB'>1048576</requested>
<address base='0x150000000'/>
</target>
- <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'>
- <zpci uid='0x0003' fid='0x00000002'/>
- </address>
+ <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0003'/>
</memory>
</devices>
</domain>
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.xml b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.xml
index 747877042a..4f9f90d1e2 100644
--- a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.xml
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-s390x.xml
@@ -39,7 +39,6 @@
<block unit='KiB'>2048</block>
<requested unit='KiB'>524288</requested>
</target>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</memory>
<memory model='virtio-mem'>
<source>
@@ -53,7 +52,6 @@
<requested unit='KiB'>1048576</requested>
<address base='0x150000000'/>
</target>
- <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
</memory>
</devices>
</domain>
--
2.45.2On 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? 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. -- Cheers, David / dhildenb
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?
>
> 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,
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?
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
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?
>>
>> 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
I did a quick test with (2), but somehow the VM does not detect the
device properly. Will do some digging if it can be easily made working.
[1] https://lkml.kernel.org/r/20250115161425.246348-1-arbab@linux.ibm.com
--
Cheers,
David / dhildenb
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
On 27.01.25 14:41, Michal Prívozník wrote: > 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. Yes, that last thing happened to me when I last looked into that ... > 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. Yes, that would be unfortunate. Looks like I have it running, so we can just support it in QEMU as it seems. We should default to CCW on s390x, though. -- Cheers, David / dhildenb
On 1/27/25 15:15, David Hildenbrand wrote: > On 27.01.25 14:41, Michal Prívozník wrote: >> 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. > > Yes, that last thing happened to me when I last looked into that ... > >> 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. > > Yes, that would be unfortunate. > > Looks like I have it running, so we can just support it in QEMU as it > seems. I see you already posted patches. Let me take a look. > We should default to CCW on s390x, though. Absolutely! And that's what my patches do too. Unless the device is explicitly placed onto PCI bus (<address type='pci'/>) libvirt puts it onto CCW, which in turn selects virtio-mem-ccw when building cmd line. Michal
On 27.01.25 15:40, Michal Prívozník wrote: > On 1/27/25 15:15, David Hildenbrand wrote: >> On 27.01.25 14:41, Michal Prívozník wrote: >>> 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. >> >> Yes, that last thing happened to me when I last looked into that ... >> >>> 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. >> >> Yes, that would be unfortunate. >> >> Looks like I have it running, so we can just support it in QEMU as it >> seems. > > I see you already posted patches. Let me take a look. > >> We should default to CCW on s390x, though. > > Absolutely! And that's what my patches do too. Unless the device is > explicitly placed onto PCI bus (<address type='pci'/>) libvirt puts it > onto CCW, which in turn selects virtio-mem-ccw when building cmd line. Great, so it's future-proof to support both. Thanks! -- Cheers, David / dhildenb
© 2016 - 2025 Red Hat, Inc.