On Thu, Dec 12 2024, Eric Auger <eric.au...@redhat.com> wrote: > On 12/12/24 10:36, Cornelia Huck wrote: >> 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. >> > Actually from a dev point of view I am not sure it changes much to have > either ARM spec rev baseline or CPU ref core named model. > > One remark is that if you look at > https://developer.arm.com/documentation/109697/2024_09?lang=en > you will see there are quite a lot of spec revisions and quite a few of > them are actually meaningful in the light of currently avaiable and > relevant HW we want to address. What I would like to avoid is to be > obliged to look at all of them in a generic manner while we just want to > address few cpu ref models.
Yes, exactly. > > Also starting from the ARM spec rev baseline the end-user may need to > add more feature opt-ins to be close to a specific cpu model. So I > foresee extra complexity for the end-user. For ref cores, it's easier to pick the ones that actually matter for a specific use case, for arch exts I don't think we can avoid implementing those we don't really care about. And yes, from the sample of cpus I've looked at they seem to be much closer to a ref core than to an arch ext.
