qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arm: "max" CPU class hierarchy changes possible?


From: Andrew Jones
Subject: Re: arm: "max" CPU class hierarchy changes possible?
Date: Thu, 11 Mar 2021 20:10:46 +0100

On Thu, Mar 11, 2021 at 06:33:15PM +0000, Peter Maydell wrote:
> On Thu, 11 Mar 2021 at 17:16, Claudio Fontana <cfontana@suse.de> wrote:
> > Maybe Peter you could clarify similarly what the intended meaning of "max" 
> > is on ARM?
> 
> "max" is "best we can do, whatever that is". (On KVM this is "same as
> the host".)
> "host" is "whatever the host is (KVM only)".
> 
> > KVM: (aarch64-only): aarch64_max_initfn():
> >
> > The following comment in the code seems wrong to me:
> >
> > /* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
> > host); */
> >
> > This is not exactly true:
> >
> > "-cpu max" calls kvm_arm_set_cpu_features_from_host(), (which checks 
> > "dtb_compatible", and if not set gets the features from the host, if set 
> > ...?)
> > After that, calls aarch64_add_sve_properties() and then adds also 
> > "svw-max-vq". This code is common with TCG.
> >
> > In the case of cpu host instead,
> >
> > "-cpu host" calls kvm_arm_set_cpu_features_from_host(), same as max, then 
> > calls aarch64_add_sve_properties() but does NOT add "svw-max-vq".
> >
> > Is this a bug?

It was left out intentionally. More below.

> 
> Maybe; that's a question for Richard or Drew...
> 
> > Are "max" and "host" for KVM supposed to be the same like with x86?

Yes, but my understanding of "max" == "host" for KVM is that that only
applies to the perspective of the guest. What CPU and what CPU features
the guest can see should be exactly the same with either "max" or "host",
depending on the enabling/disabling of any optional CPU properties.

The question here seems to be that, if one has a CPU property, does that
imply the other should have the same? Which would effectively allow the
two to be aliases (when KVM is enabled). I don't know, does x86 ensure
100% property compatibility?

I opted not to support sve-max-vq for "host" because I consider it a
legacy CPU property, one I didn't want to propagate. Indeed it may
make more sense to depreciate sve-max-vq than to "fix" this issue
by adding it to "host". Note, we can already create equivalent SVE
CPUs. The following are the same from the perspective of the guest

 -accel kvm -cpu host,sve512=on
 -accel kvm -cpu max,sve512=on

And, for TCG, these are the same from the perspective of the guest
 
 -accel tcg -cpu max,sve512=on
 -accel tcg -cpu max,sve-max-vq=4

So we already don't need sve-max-vq.

Thanks,
drew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]