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

[Peter Krempa]

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.