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

Hi. On Wed, Nov 16, 2022 at 22:53:18 +0530, manish.mishra wrote: 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. 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). 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. 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. 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