On Thu, 19 Dec 2024 11:35:16 +0000,
Kashyap Chamarthy <kcham...@redhat.com> wrote:
>
> On Thu, Dec 12, 2024 at 11:04:30AM +0100, Eric Auger wrote:
>
> Hi Eric,
>
> > On 12/12/24 10:36, Cornelia Huck wrote:
> > > On Thu, Dec 12 2024, Daniel P. Berrangé <berra...@redhat.com> wrote:
>
> [...]
>
> > >> 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.
> >
> > 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.
>
> (Assuming I'm parsing your last para right; correct me if not.)
>
> Isn't a user wanting to add extra CPU flags (on top of a baseline) a
> "normal behaviour" and not "extra complexity"? Besides coming close to
> a specific CPU model, there's the additional important use-case of CPU
> flags that provide security mitigation.
>
> Consider this:
>
> Say, there's a serious security issue in a released ARM CPU. As part of
> the fix, two new CPU flags need to be exposed to the guest OS, call them
> "secflag1" and "secflag2". Here, the user is configuring a baseline
> model + two extra CPU flags, not to get close to some other CPU model
> but to mitigate itself against a serious security flaw.
If there's such a security issue, that the hypervisor's job to do so,
not userspace. See what KVM does for CSV3, for example (and all the
rest of the side-channel stuff).
You can't rely on userspace for security, that'd be completely
ludicrous.
M.
--
Without deviation from the norm, progress is not possible.
