All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Haibo Xu <haibo.xu@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	qemu-arm@nongnu.org, philmd@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 7/7] target/arm/cpu: spe: Enable spe to work with host cpu
Date: Tue, 11 Aug 2020 18:49:54 +0200	[thread overview]
Message-ID: <20200811164954.s2sdjzpqpdh2orks@kamzik.brq.redhat.com> (raw)
In-Reply-To: <CAJc+Z1F_vFdJuy2kZnj0gZSOd_8-=rSfWFHjQSPU5XEKQ2KZkg@mail.gmail.com>

On Tue, Aug 11, 2020 at 11:15:42AM +0800, Haibo Xu wrote:
> > > +    if (!cpu->has_spe || !kvm_enabled()) {
> > > +        unset_feature(env, ARM_FEATURE_SPE);
> > > +    }
> >
> > I don't think this should be necessary.
> >
> 
> Yes, I have tried to remove this check, and the vSPE can still work
> correctly.
> But I don't know whether there are some corner cases that trigger an error.
> The similar logic is added in commit 929e754d5a to enable vPMU support.

I think the PMU logic needs a cleanup, rather than to be imitated.

> 
> > > +
> > >      if (!arm_feature(env, ARM_FEATURE_EL2)) {
> > >          /* Disable the hypervisor feature bits in the processor feature
> > >           * registers if we don't have EL2. These are id_pfr1[15:12] and
> > > diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
> > > index be045ccc5f..4ea58afc1d 100644
> > > --- a/target/arm/kvm64.c
> > > +++ b/target/arm/kvm64.c
> > > @@ -679,6 +679,7 @@ bool
> kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
> > >      features |= 1ULL << ARM_FEATURE_AARCH64;
> > >      features |= 1ULL << ARM_FEATURE_PMU;
> > >      features |= 1ULL << ARM_FEATURE_GENERIC_TIMER;
> > > +    features |= 1ULL << ARM_FEATURE_SPE;
> >
> > No, SPE is not a feature we assume is present in v8.0 CPUs.
> >
> 
> Yes, SPE is an optional feature for v8.2. How about changing to the
> following logic:
> 
> spe_supported = ioctl(fdarray[0], KVM_CHECK_EXTENSION, KVM_CAP_ARM_SPE_V1)
> > 0;
> if (spe_supported) {
>     features |= 1ULL << ARM_FEATURE_SPE;
> }

Yes, except you need to drop the ARM_FEATURE_SPE define and use the ID
register bit instead like "sve_supported" does.

> 
> > >
> > >      ahcf->features = features;
> > >
> > > @@ -826,6 +827,14 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > >      } else {
> > >          env->features &= ~(1ULL << ARM_FEATURE_PMU);
> > >      }
> > > +    if (!kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_SPE_V1)) {
> > > +        cpu->has_spe = false;
> > > +    }
> > > +    if (cpu->has_spe) {
> > > +        cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_SPE_V1;
> > > +    } else {
> > > +        env->features &= ~(1ULL << ARM_FEATURE_SPE);
> > > +    }
> >
> > The PMU code above this isn't a good pattern to copy. The SVE code below
> > is better. SVE uses an ID bit and doesn't do the redundant KVM cap check.
> > It'd be nice to cleanup the PMU code (with a separate patch) and then add
> > SPE in a better way.
> >
> 
> I noticed that Peter had sent out a mail
> <https://www.mail-archive.com/qemu-devel@nongnu.org/msg727640.html> to talk
> about the feature-identification strategy.
> So shall we adapt it to the vPMU and vSPE feature?

At least SPE. You'll have to double check that it makes sense to do for
PMU. But, if so, then it should be done with a separate series.

Thanks,
drew



  reply	other threads:[~2020-08-11 16:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-07  8:10 [PATCH 0/7] target/arm: Add vSPE support to KVM guest Haibo Xu
2020-08-07  8:10 ` [PATCH 1/7] update Linux headers with new vSPE macros Haibo Xu
2020-08-07  8:10 ` [PATCH 2/7] target/arm/kvm: spe: Add helper to detect SPE when using KVM Haibo Xu
2020-08-14 19:16   ` Richard Henderson
2020-08-07  8:10 ` [PATCH 3/7] target/arm/cpu: spe: Add an option to turn on/off vSPE support Haibo Xu
2020-08-07  8:28   ` Philippe Mathieu-Daudé
2020-08-10  3:03     ` Haibo Xu
2020-08-10 10:14       ` Philippe Mathieu-Daudé
2020-08-10 10:50   ` Andrew Jones
2020-08-14 19:03     ` Richard Henderson
2020-08-14 19:15   ` Richard Henderson
2020-08-07  8:10 ` [PATCH 4/7] target/arm/kvm: spe: Unify device attr operatioin helper Haibo Xu
2020-08-07  8:19   ` Philippe Mathieu-Daudé
2020-08-10  2:48     ` Haibo Xu
2020-08-10 10:29       ` Andrew Jones
2020-08-11  1:13         ` Haibo Xu
2020-08-07  8:10 ` [PATCH 5/7] target/arm/kvm: spe: Add device init and set_irq operations Haibo Xu
2020-08-07  8:10 ` [PATCH 6/7] hw/arm/virt: spe: Add SPE fdt binding for virt machine Haibo Xu
2020-08-10 11:05   ` Andrew Jones
2020-08-11  2:38     ` Haibo Xu
2020-08-11 16:38       ` Andrew Jones
2020-08-12  0:42         ` Haibo Xu
2020-08-29 15:21   ` Auger Eric
2020-08-31  6:27     ` Haibo Xu
2020-08-07  8:10 ` [PATCH 7/7] target/arm/cpu: spe: Enable spe to work with host cpu Haibo Xu
2020-08-10 11:16   ` Andrew Jones
2020-08-11  3:15     ` Haibo Xu
2020-08-11 16:49       ` Andrew Jones [this message]
2020-08-12  0:54         ` Haibo Xu
2020-08-14 19:28         ` Richard Henderson
2020-08-15  7:17           ` Andrew Jones
2020-08-10 10:43 ` [PATCH 0/7] target/arm: Add vSPE support to KVM guest Andrew Jones
2020-08-31  7:56 ` Auger Eric
2020-09-01  2:26   ` Haibo Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200811164954.s2sdjzpqpdh2orks@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=haibo.xu@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.