Add option to skip cpu feature and model verification in libvirt and rely on qemu 'enforce' option

[Jiri Denemark]

Hi.

On Wed, Nov 16, 2022 at 22:53:18 +0530, manish.mishra wrote:
> We had a requirement to skip all CPU feature validations from libvirt
> and totally rely on Qemu for following reasons.

You are mixing two different things here. The "enforce" CPU checking for
making sure a guest gets exactly what the user asked QEMU for and
missing CPU models or features support in libvirt.

>   * As libvirt always lies behind in term of cpu feature management
>   compare to qemu, so we may not be able to use all of the latest
>   support provided by qemu till it is updated in libvirt too. For
>   example like if new cpu features are added in qemu but not yet
>   updated in libvirt.

So you effectively ask for a "passthrough" configuration, that is, CPU
model and features would be passed directly to QEMU without libvirt even
looking at them, right?

Anyway, the current goal is to make libvirt ask for supported CPU models
including their definition so that we don't have to keep our own
definitions. That is, libvirt would support all models as they are added
to QEMU without any additional work. Not sure if CPU features would
follow, but adding them is fairly easy and what's more important they
don't change in time (unlike CPU models).

>   * Libvirt checks if a features is supported or not based on cpuid, a
>   feature supported by host may not be supported by qemu or there can
>   be some features which are emulated by Qemu so libvirt level
>   checking does not make sense in those cases.

This has not been the case for several years already. Libvirt asks QEMU
what CPU features it can provide on the host (either natively or
emulated) and checks against them. So no issue here. Well, expect that
some features are strange and QEMU does not report them as enabled for
-cpu host even though it would enable them for some specific CPU models.
But that's more in a "bug" area which needs to be solved between QEMU
and libvirt rather than being it a principal issue.

>   * Qemu already provide an option 'enforce' to validate if features
>   with which vm is started is exactly same as one provided and nothing
>   is silently dropped.

Right, but it's not enough. In addition to removed features libvirt also
checks for unexpectedly added features. And you really need to do both.
Because if you ask for -cpu Model,feat1=on,feat2=on,enforce and QEMU
says everything is fine, the guest might see more than what you asked.
For example, if a feature is enabled only if a host supports it you may
or may not get it without any complains from QEMU. But if you get it you
really need to explicitly ask for it during migration, otherwise the
feature can just silently disappear. Of course, this would be a really
bad behavior from QEMU, but that does not mean it can't happen (I think
SVM is a bit problematic in this way) and the whole point of libvirt's
checks is to prevent this kind of issues.

So once QEMU starts we checks all features enabled in the vCPU and note
those that were (unexpectedly) added so that we can explicitly ask for
them during migration and also check that no other features were added
on top. And for this whole process to work, we need to understand, i.e.,
have explicit support, for all CPU features (QEMU report a lot of CPU
properties and we need to know which one needs to be stored as enabled
features) and CPU models to make sure both sides of migration understand
the CPU definition in domain XML in the same way.

> Basically we want another check option like 'qemu-enforce' which will
> skip all feature and cpu model verfications in libvirt and pass
> 'enforce' option to qemu. It will work similar to check 'none' i mean
> no check to verify if provide features are supported by host, also on
> top of that skip things like virCPUValidateFeatures where ever
> required.

In short, I don't think this is a good idea and we should or could
support it and still maintain migration safety. If you don't care about
migration safety, you don't need to care about "enforce" QEMU check
either and can just use host-passthrough and get whatever QEMU supports
on the host.

Jirka