Re: [libvirt] [PATCH v1 00/26] move qemucaps validations from qemu_command to qemu_domain
On 12/10/19 6:41 PM, Cole Robinson wrote:
On 12/9/19 6:15 PM, Daniel Henrique Barboza wrote:
> (series based on master commit 97cafa610ecf5)
>
[...]
The hotplug code should already be calling into Validate code. When a
device is hotplugged via qemu_driver, we get:
qemu_driver.c
-> qemuDomainAttachDeviceFlags
-> qemuDomainAttachDeviceLiveAndConfig
-> virDomainDeviceDefParse
-> virDomainDeviceDefValidate
-> deviceValidateCallback
-> qemuDomainDeviceDefValidate
So if device validation is moved into the correct
qemuDomainDeviceDefValidateXXX function it will get called in the
hotplug path so they won't be lost.
Good to know. I assumed that the hotplug path was separated.
Perhaps this info can be put somewhere in the docs folder as reference. This
appears to be the kind of call hierarchy that doesn't change that often, so
it wouldn't be a burden to keep the doc updated.
> - moving CPU Model validation is trickier than the rest because
> there are code in DefPostParse() that makes CPU Model changes that
> are then validated in qemu_command.c. Moving the validation to define
> time doesn't cut in this case - the validation is considering
> PostParse changes in the CPU Model and some of the will fail if
> done by qemuDomainDefValidate time. I didn't think too much about
> how to handle this case, but given that the approach would be
> different from the other cases handled here, I left it out too.
>
Hmm I glanced at the qemuBuildCpuModelArgStr checks but it doesn't
strike me why those are an issue. Validate should always be triggered
after PostParse, so the ordering of those two shouldn't impact things
here. But I didn't attempt the change
Unfortunately I've erased the error I was seeing in this case. I recall
something to do with VIR_CPU_MODE_HOST_MODEL being set in
qemuDomainDefSetDefaultCPU(), but TBH it's easier to just move the code again
and see what happens.
>
I suspect a bug on your side. qemu_command.c has:
I'll attempt that in the next iterations of this work.
Thanks,
Daniel