Re: [libvirt PATCH 00/19] RFC: Add versioned CPUs to libvirt

Hi. Originally I was thinking about versioned CPU models support as a good opportunity for redoing the way they are defined in libvirt and the way we check their compatibility with the current host setup. In other words, I wanted each new CPU model definition to be probed from QEMU and drop check="partial" for these new models and rely on CPU runnability reported by QEMU. But this would require additional support from QEMU, for which there were some patches sent to the list, but nothing was really merged in the end. So I guess we need to accept the situation and add versioned CPU models the old way without waiting for changes in QEMU that nobody is working on anyway. But I wonder if we should still try to change the way we check guest CPU ABI a bit (for the newly added models) and rely more on QEMU not changing their CPU models. I believe they will never change an existing versioned model and introduce a new one instead, is that correct? On Mon, Nov 06, 2023 at 16:21:05 -0600, Jonathon Jongsma wrote: Hmm, I don't think creating aliases is a good idea, at least on the public API level. We could perhaps use them internally if needed (and if QEMU doesn't provide that info) when implementing a transformation of non-versioned CPUs to versioned ones. But providing the same CPU model under several different names doesn't seem like a good idea. Well the tests are mostly there to avoid such churn because it's indeed an issue if the same CPU suddenly starts to be recognized as a different model. Sometimes the change is correct, but most of the time it's not. So using your example, having EPYC-v2 in domain XML instead of EPYC-IBPB means you cannot migrate to an libvirt version that doesn't know about EPYC-v2 despite it being exactly the same as the supported EPYC-IBPB CPU model. Which is why introducing aliases in public APIs is not a good idea. That said, if we want to implement the translation from non-versioned to versioned CPU models we need to solve migration if Model is translated as Model-v2, which the other side does not support. I'm afraid we would need to do some kind of reverse translation here. I've said in my other emails that this is not a good idea so I'll explain why in detail here. Taking an example from your patch that updates several EPYC models, let's suppose we have an EPYC CPU model defined without "npt" and we decide to add "npt" to the model definition. On the source with new libvirt with this change we start a domain with the following CPU definition (simplified): <cpu> <model>EPYC</model> </cpu> Now if the source host cannot provide npt, we're good as the CPU definition will be translated to something like <cpu> <model>EPYC</model> <feature name="npt" policy="disable"/> </cpu> because we detected that QEMU removed the npt feature even though we asked for it by using EPYC. But if the host can provide npt the live XML will not be updated. Note, in real world CPUs missing a feature we're adding might not actually exist and everything would be fine, but once we're in nested environment, everything is possible. Also there are features that can be available on a host CPU based on its configuration or even microcode revision. Once we try to migrate such domain to a destination host with older libvirt without npt in EPYC, it will ask QEMU to run a domain with EPYC CPU model. In case the destination host cannot provide npt (in contrast to the source host), the guest will see npt disabled and we won't detect it as an issue because we didn't know we were asking for it by using EPYC. Actually, we might still detect it as a list of features QEMU disabled would not be empty (in case it was new enough to have npt in EPYC). And when we want to remove a feature from a model, new libvirt and QEMU on the source will not provide the removed feature, but older libvirt on the destination host will require it because the feature is part our the CPU model definition there. All this, while using a specific example, was meant rather generally. And I didn't cover all possible combinations of what can happen on each side. There might be cases when we can add or drop CPU features from existing models, but each case needs to be considered separately and be accompanied with detailed description why such change would not cause migration issues. And doing so is usually not very pleasant mental exercise as you can see above :-) Jirka