Although a ramfb video device is not a PCI device, we don't currently
report an error for ramfb device definitions containing a PCI address.
However, a guest configured with such a device will fail to start:
# virsh start test1
error: Failed to start domain test1
error: internal error: qemu unexpectedly closed the monitor: 2020-06-16T05:23:02.759221Z qemu-kvm: -device ramfb,id=video0,bus=pcie.0,addr=0x1: Device 'ramfb' can't go on PCIE bus
A better approach is to reject any device definitions that contain PCI
addresses. While this is a change in behavior, any existing
configurations were non-functional.
https://bugzilla.redhat.com/show_bug.cgi?id=1847259
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
---
changes in v2:
- move validation to qemu-specific validation function as suggested by Laine
src/qemu/qemu_validate.c | 8 ++++++++
tests/qemuxml2argvtest.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 5082a29dc7..b13c03759e 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -1925,6 +1925,14 @@ qemuValidateDomainDeviceDefVideo(const virDomainVideoDef *video,
if (qemuValidateDomainVirtioOptions(video->virtio, qemuCaps) < 0)
return -1;
+ if (video->type == VIR_DOMAIN_VIDEO_TYPE_RAMFB &&
+ video->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("'address' is not supported for 'ramfb' video devices"));
+ return -1;
+ }
+
+
return 0;
}
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 1195f9c982..f2522fa530 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2276,6 +2276,7 @@ mymain(void)
QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS);
DO_TEST_CAPS_LATEST("video-bochs-display-device");
DO_TEST_CAPS_LATEST("video-ramfb-display-device");
+ DO_TEST_CAPS_LATEST_PARSE_ERROR("video-ramfb-display-device-pci-address");
DO_TEST("video-none-device",
QEMU_CAPS_VNC);
DO_TEST_PARSE_ERROR("video-invalid-multiple-devices", NONE);
--
2.21.3
On 6/25/20 10:34 AM, Jonathon Jongsma wrote: > Although a ramfb video device is not a PCI device, we don't currently > report an error for ramfb device definitions containing a PCI address. > However, a guest configured with such a device will fail to start: > > # virsh start test1 > error: Failed to start domain test1 > error: internal error: qemu unexpectedly closed the monitor: 2020-06-16T05:23:02.759221Z qemu-kvm: -device ramfb,id=video0,bus=pcie.0,addr=0x1: Device 'ramfb' can't go on PCIE bus > > A better approach is to reject any device definitions that contain PCI > addresses. While this is a change in behavior, any existing > configurations were non-functional. > > https://bugzilla.redhat.com/show_bug.cgi?id=1847259 > > Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> > --- > changes in v2: > - move validation to qemu-specific validation function as suggested by Laine > > src/qemu/qemu_validate.c | 8 ++++++++ > tests/qemuxml2argvtest.c | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c > index 5082a29dc7..b13c03759e 100644 > --- a/src/qemu/qemu_validate.c > +++ b/src/qemu/qemu_validate.c > @@ -1925,6 +1925,14 @@ qemuValidateDomainDeviceDefVideo(const virDomainVideoDef *video, > if (qemuValidateDomainVirtioOptions(video->virtio, qemuCaps) < 0) > return -1; > > + if (video->type == VIR_DOMAIN_VIDEO_TYPE_RAMFB && > + video->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) { > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > + _("'address' is not supported for 'ramfb' video devices")); > + return -1; > + } > + > + > return 0; > } > > diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c > index 1195f9c982..f2522fa530 100644 > --- a/tests/qemuxml2argvtest.c > +++ b/tests/qemuxml2argvtest.c > @@ -2276,6 +2276,7 @@ mymain(void) > QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS); > DO_TEST_CAPS_LATEST("video-bochs-display-device"); > DO_TEST_CAPS_LATEST("video-ramfb-display-device"); > + DO_TEST_CAPS_LATEST_PARSE_ERROR("video-ramfb-display-device-pci-address"); Did you forget to git-add the test case data? > DO_TEST("video-none-device", > QEMU_CAPS_VNC); > DO_TEST_PARSE_ERROR("video-invalid-multiple-devices", NONE); > With the test case data added Reviewed-by: Laine Stump <laine@redhat.com>
On Thu, 2020-06-25 at 12:20 -0400, Laine Stump wrote: > On 6/25/20 10:34 AM, Jonathon Jongsma wrote: > > Although a ramfb video device is not a PCI device, we don't > > currently > > report an error for ramfb device definitions containing a PCI > > address. > > However, a guest configured with such a device will fail to start: > > > > # virsh start test1 > > error: Failed to start domain test1 > > error: internal error: qemu unexpectedly closed the monitor: > > 2020-06-16T05:23:02.759221Z qemu-kvm: -device > > ramfb,id=video0,bus=pcie.0,addr=0x1: Device 'ramfb' can't go on > > PCIE bus > > > > A better approach is to reject any device definitions that contain > > PCI > > addresses. While this is a change in behavior, any existing > > configurations were non-functional. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1847259 > > > > Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> > > --- > > changes in v2: > > - move validation to qemu-specific validation function as > > suggested by Laine > > > > src/qemu/qemu_validate.c | 8 ++++++++ > > tests/qemuxml2argvtest.c | 1 + > > 2 files changed, 9 insertions(+) > > > > diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c > > index 5082a29dc7..b13c03759e 100644 > > --- a/src/qemu/qemu_validate.c > > +++ b/src/qemu/qemu_validate.c > > @@ -1925,6 +1925,14 @@ qemuValidateDomainDeviceDefVideo(const > > virDomainVideoDef *video, > > if (qemuValidateDomainVirtioOptions(video->virtio, qemuCaps) > > < 0) > > return -1; > > > > + if (video->type == VIR_DOMAIN_VIDEO_TYPE_RAMFB && > > + video->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) { > > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > > + _("'address' is not supported for 'ramfb' > > video devices")); > > + return -1; > > + } > > + > > + > > return 0; > > } > > > > diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c > > index 1195f9c982..f2522fa530 100644 > > --- a/tests/qemuxml2argvtest.c > > +++ b/tests/qemuxml2argvtest.c > > @@ -2276,6 +2276,7 @@ mymain(void) > > QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS); > > DO_TEST_CAPS_LATEST("video-bochs-display-device"); > > DO_TEST_CAPS_LATEST("video-ramfb-display-device"); > > + DO_TEST_CAPS_LATEST_PARSE_ERROR("video-ramfb-display-device- > > pci-address"); > > Did you forget to git-add the test case data? OK, well that points out an interesting property of the DO_TEST_CAPS_LATEST_PARSE_ERROR() macro. It passed the 'make check' because it failed to parse the xml file as expected. But the reason it failed was obviously not the reason I expected it to fail... I want it to fail due to the specifying a PCI address for the ramfb device. But it actually fails because the xml file didn't exist... :/ > > > > DO_TEST("video-none-device", > > QEMU_CAPS_VNC); > > DO_TEST_PARSE_ERROR("video-invalid-multiple-devices", NONE); > > > > With the test case data added > > Reviewed-by: Laine Stump <laine@redhat.com>
On 6/25/20 12:30 PM, Jonathon Jongsma wrote: > On Thu, 2020-06-25 at 12:20 -0400, Laine Stump wrote: >> On 6/25/20 10:34 AM, Jonathon Jongsma wrote: >>> Although a ramfb video device is not a PCI device, we don't >>> currently >>> report an error for ramfb device definitions containing a PCI >>> address. >>> However, a guest configured with such a device will fail to start: >>> >>> # virsh start test1 >>> error: Failed to start domain test1 >>> error: internal error: qemu unexpectedly closed the monitor: >>> 2020-06-16T05:23:02.759221Z qemu-kvm: -device >>> ramfb,id=video0,bus=pcie.0,addr=0x1: Device 'ramfb' can't go on >>> PCIE bus >>> >>> A better approach is to reject any device definitions that contain >>> PCI >>> addresses. While this is a change in behavior, any existing >>> configurations were non-functional. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1847259 >>> >>> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> >>> --- >>> changes in v2: >>> - move validation to qemu-specific validation function as >>> suggested by Laine >>> >>> src/qemu/qemu_validate.c | 8 ++++++++ >>> tests/qemuxml2argvtest.c | 1 + >>> 2 files changed, 9 insertions(+) >>> >>> diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c >>> index 5082a29dc7..b13c03759e 100644 >>> --- a/src/qemu/qemu_validate.c >>> +++ b/src/qemu/qemu_validate.c >>> @@ -1925,6 +1925,14 @@ qemuValidateDomainDeviceDefVideo(const >>> virDomainVideoDef *video, >>> if (qemuValidateDomainVirtioOptions(video->virtio, qemuCaps) >>> < 0) >>> return -1; >>> >>> + if (video->type == VIR_DOMAIN_VIDEO_TYPE_RAMFB && >>> + video->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) { >>> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", >>> + _("'address' is not supported for 'ramfb' >>> video devices")); >>> + return -1; >>> + } >>> + >>> + >>> return 0; >>> } >>> >>> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c >>> index 1195f9c982..f2522fa530 100644 >>> --- a/tests/qemuxml2argvtest.c >>> +++ b/tests/qemuxml2argvtest.c >>> @@ -2276,6 +2276,7 @@ mymain(void) >>> QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS); >>> DO_TEST_CAPS_LATEST("video-bochs-display-device"); >>> DO_TEST_CAPS_LATEST("video-ramfb-display-device"); >>> + DO_TEST_CAPS_LATEST_PARSE_ERROR("video-ramfb-display-device- >>> pci-address"); >> Did you forget to git-add the test case data? > OK, well that points out an interesting property of the > DO_TEST_CAPS_LATEST_PARSE_ERROR() macro. It passed the 'make check' > because it failed to parse the xml file as expected. But the reason it > failed was obviously not the reason I expected it to fail... I want it > to fail due to the specifying a PCI address for the ramfb device. But > it actually fails because the xml file didn't exist... :/ That gave me the best laugh I'd had all day!! :-) I just realized you don't have push privileges on gitlab. If you re-send with test case data, I'll push it. (I guess we should also fix the test harness to "fail to fail" if the test case data is missing, but that's a separate issue)
© 2016 - 2024 Red Hat, Inc.