Re: [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable aarch64 KVM host model

[Kashyap Chamarthy]

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é <berrange@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.

An example that comes to mind is the infamous "speculative store bypass"
(SSB) vulnerability and how QEMU addressed it[1][2] in x86.  I'm sure,
as you know, it also affects ARM[3].


[1] https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04796.html
    — i386: define the 'ssbd' CPUID feature bit (CVE-2018-3639)

[2] https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04797.html
    — i386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639)

[3] 
https://developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registers/SSBS--Speculative-Store-Bypass-Safe

-- 
/kashyap