[PATCH 4/4] qemu: validate: Prefer existing qemuCaps

[Michal Privoznik]

On 12/8/20 4:20 PM, Peter Krempa wrote:
> On Tue, Dec 08, 2020 at 16:09:07 +0100, Michal Privoznik wrote:
>> On 12/8/20 3:01 PM, Peter Krempa wrote:
>>> The validation callback always fetched a fresh copy of 'qemuCaps' to use
>>> for validation which is wrong in cases when the VM is already running,
>>> such as device hotplug. The newly-fetched qemuCaps may contain flags
>>> which weren't originally in use when starting the VM e.g. on a libvirtd
>>> upgrade.
>>>
>>> Since the post-parse/validation machinery has a per-run 'parseOpaque'
>>> field filled with qemuCaps of the actual process we can reuse the caps
>>> in cases when we get them.
>>>
>>> The code still fetches a fresh copy if parseOpaque doesn't have a
>>> per-run copy to preserve existing functionality.
>>>
>>> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
>>> ---
>>>    src/qemu/qemu_validate.c | 30 ++++++++++++++++++++----------
>>>    1 file changed, 20 insertions(+), 10 deletions(-)
>>
>>
>> So this will use the old qemuCaps even though a feature might already be
>> available in qemu but libvirt didn't detect it. For instance the virtio-pmem
>> I'm implementing - guests started today won't have the qemuCap for
>> virtio-pmem because it's not implemented yet. But when they update libvirt
>> they still won't get the feature because we're using old qemuCaps for
>> validation and thus new memory model will be denied because of lacking
>> capability.
> 
> Oh, this is actually what we do and it's required! Old libvirt might
> have configured the device in a way which is not compatible with the new
> one and thus attempting to talk to it using the new interface would just
> break.
> 
> We currently store the old state of 'qemuCaps' and everything uses it in
> the state when the VM was started. Well except for the validator, which
> was broken and this patchset is fixing it.
> 
> You will never get new features with an old VM.
> 

Okay then.

Michal