[libvirt] [PATCH v1 00/26] move qemucaps validations from qemu_command to qemu_domain

Daniel Henrique Barboza danielhb413 at gmail.com
Tue Dec 10 22:39:22 UTC 2019



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




More information about the libvir-list mailing list