On Thu, Dec 12 2024, Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Thu, Dec 12, 2024 at 09:12:33AM +0100, Eric Auger wrote: >> Connie, >> >> On 12/6/24 12:21, Cornelia Huck wrote: >> > A respin/update on the aarch64 KVM cpu models. Also available at >> > gitlab.com/cohuck/qemu arm-cpu-model-rfcv2 > > snip > >> From a named model point of view, since I do not see much traction >> upstream besides Red Hat use cases, targetting ARM spec revision >> baselines may be overkill. Personally I would try to focus on above >> models: AltraMax, AmpereOne, Grace, ... Or maybe the ARM cores they may >> be derived from. > > If we target modelling of vendor named CPU models, then beware that > we're opening the door to an very large set (potentially unbounded) > of named CPU models over time. If we target ARM spec baselines then > the set of named CPU models is fairly modest and grows slowly. > > Including ARM spec baselines will probably reduce the demand for > adding vendor specific named models, though I expect we'll still > end up wanting some, or possibly even many. > > Having some common baseline models is likely useful for mgmt > applications in other ways though. > > Consider you mgmt app wants to set a CPU model that's common across > heterogeneous hardware. They don't neccessarily want/need to be > able to live migrate between heterogeneous CPUs, but for simplicity > of configuration desire to set a single named CPU across all guests, > irrespective of what host hey are launched on. The ARM spec baseline > named models would give you that config simplicity. If we use architecture extensions (i.e. Armv8.x/9.x) as baseline, I'm seeing some drawbacks: - a lot of work before we can address some specific use cases - old models can get new optional features - a specific cpu might have a huge set of optional features on top of the baseline model Using a reference core such as Neoverse-V2 probably makes more sense (easier to get started, less feature diff?) It would still make a good starting point for a simple config.
