Re: Add option to skip cpu feature and model verification in libvirt and rely on qemu 'enforce' option
On Fri, Nov 18, 2022 at 10:18:59 +0000, John Levon wrote:
On Fri, Nov 18, 2022 at 10:52:32AM +0100, Jiri Denemark wrote:
> > * 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.
Hi Jiri, I'm not following this very well. I think you're saying that qemu has
had bugs previously where features get silently enabled,
Personally, I haven't actually witnessed any bug in this area (as far as
I can remember, which is not that far :-)), but got some reports of at
least one, even though without any proof.
Specifically, SVM is quite strange as it is included in all AMD CPU
models in QEMU and yet if you try to start it on a host without nesting
enabled "enforce" does not complain. I saw the feature is enabled with
older machine types, but I was told the magic behind this feature looks
like not only machine type but even host configuration itself is
involved. Anyway, although I saw reports of that the feature could be
enabled without an explicit request even with new machine types I still
haven't seen any proof of this happening. So I hope it just does not
happen and users are only afraid of this possibility.
and it's libvirt's job/role to paper over those issues? Do
you have
some specific cases of this?
This is not about papering. It's actually the opposite, that is about
detecting if something like this happens and reporting it as a failure
rather than papering it and hoping everything goes well. So I think
doing this is a good idea even though I don't think we actually saw any
issue of this kind.
Jirka