Bug 1598657
| Summary: | libvirt treats spapr-vio addresses as 64-bit, but they're not | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | David Gibson <dgibson> |
| Component: | libvirt | Assignee: | Andrea Bolognani <abologna> |
| Status: | CLOSED ERRATA | QA Contact: | Dan Zheng <dzheng> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 8.1 | CC: | abologna, dzheng, haizhao, jdenemar, knoel, yalzhang |
| Target Milestone: | rc | Flags: | knoel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-5.5.0-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-06 07:11:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I got sick of seeing this bug in my searches, and wrote a patch for it, which I posted to libvir-list upstream (and CCed Andrea). Andrea, can you help with shepherding that into upstream libvirt? Alternative approach posted upstream. https://www.redhat.com/archives/libvir-list/2019-June/msg00393.html Fix merged upstream.
commit 89afb9f594877d9cc105d729143a7b05528570da
Author: Andrea Bolognani <abologna>
Date: Fri Jun 14 12:50:22 2019 +0200
qemu: Validate spapr-vio addresses
According to sPAPR, addresses are 32-bit rather than 64-bit.
Update qemuDomainDeviceDefValidateAddress() accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=1598657
Signed-off-by: Andrea Bolognani <abologna>
Reviewed-by: Michal Privoznik <mprivozn>
v5.4.0-276-g89afb9f594
Reproduce:
libvirt-5.4.0-2.module+el8.1.0+3523+b348b848
qemu-kvm-4.0.0-4.module+el8.1.0+3523+b348b848.ppc64le
kernel-4.18.0-109.el8.ppc64le
Edit spapr-vio device's address from 0x30000000 to 0x300000000
<serial type='pty'>
<target type='spapr-vio-serial' port='0'>
<model name='spapr-vty'/>
</target>
<address type='spapr-vio' reg='0x300000000'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
<address type='spapr-vio' reg='0x300000000'/>
</console>
Start guest
# virsh start avocado-vt-vm1
error: Failed to start domain avocado-vt-vm1
error: internal error: process exited while connecting to monitor: 2019-07-04T00:54:09.488932Z qemu-kvm: -device spapr-vty,chardev=charserial0,id=serial0,reg=0x300000000: Parameter 'reg' expects uint32_t
--- libvirt does not report error for 0x300000000
Retest with:
libvirt-5.5.0-1.module+el8.1.0+3580+d7f6488d.ppc64le
qemu-kvm-4.0.0-4.module+el8.1.0+3523+b348b848.ppc64le
kernel-4.18.0-109.el8.ppc64le
Use same xml as above and start guest
# virsh start avocado-vt-vm1
error: Failed to start domain avocado-vt-vm1
error: unsupported configuration: spapr-vio reg='0x300000000' exceeds maximum possible value (0xffffffff)
--- libvirt report the checking error.
Based on comment 9, I mark it verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723 |
Description of problem: The "spapr-vio" address type used for PAPR defined virtual devices on IBM POWER machines is treated by libvirt as being a 64-bit value (unsigned long long) typedef struct _virDomainDeviceSpaprVioAddress virDomainDeviceSpaprVioAddress; typedef virDomainDeviceSpaprVioAddress *virDomainDeviceSpaprVioAddressPtr; struct _virDomainDeviceSpaprVioAddress { unsigned long long reg; bool has_reg; }; However, both in the PAPR spec and the qemu implementation the address is only 32-bit. 64-bit values have never been supported there. Version-Release number of selected component (if applicable): Current upstream (d999b6016b4e9e39e23bb8bd043abe576305daf1) Additional info: The description in the VDAG is also incorrect ยง 24.18.3 https://access.qa.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_deployment_and_administration_guide/#sect-Devices-Device_addresses