Hi On Fri, Mar 7, 2025 at 3:58 PM Martin Kletzander <mkletzan@xxxxxxxxxx> wrote: > > On Tue, Feb 18, 2025 at 02:16:10PM +0400, marcandre.lureau@xxxxxxxxxx wrote: > >From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > >Without an error message, it can be tedious to figure out failure to > >start, just fall-through the generic range error. > > > >Signed-off-by: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > >--- > > src/qemu/qemu_command.c | 1 - > > 1 file changed, 1 deletion(-) > > > >diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c > >index 54130ac4f0..772e98fbb4 100644 > >--- a/src/qemu/qemu_command.c > >+++ b/src/qemu/qemu_command.c > >@@ -8448,7 +8448,6 @@ qemuBuildGraphicsCommandLine(virQEMUDriverConfig *cfg, > > break; > > case VIR_DOMAIN_GRAPHICS_TYPE_RDP: > > case VIR_DOMAIN_GRAPHICS_TYPE_DESKTOP: > >- return -1; > > You're right that we're missing an error message here, but > > > case VIR_DOMAIN_GRAPHICS_TYPE_LAST: > > default: > > virReportEnumRangeError(virDomainGraphicsType, graphics->type); > > This reports an error that corresponds to a completely invalid value > provided in the internal code as an error in the code. I would be fine > with it if the validation function qemuValidateDomainDeviceDefGraphics() > threw an error for anyone requesting such an unsupported configuration, > but that does not. We should either add it there or just add a proper > error message here. It is not possible to trigger now unless someone is > adding a previously unsupported graphics type, but still, would be nice > to lead by an example. I'll drop this patch.
