qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>, qemu-devel@nongnu.org
Subject: Re: [PULL 09/11] target/arm/kvm: host cpu: Add support for sve<N> properties
Date: Thu, 3 Feb 2022 18:36:40 +0100	[thread overview]
Message-ID: <20220203173640.shxkmatdcsfzzvtj@gator> (raw)
In-Reply-To: <CAFEAcA8pS6_SYWMFJ0=EyHVQ9V1MTiM_OCjkvqb5znqJ91w_qw@mail.gmail.com>

On Thu, Feb 03, 2022 at 04:46:21PM +0000, Peter Maydell wrote:
> On Fri, 1 Nov 2019 at 08:51, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > From: Andrew Jones <drjones@redhat.com>
> >
> > Allow cpu 'host' to enable SVE when it's available, unless the
> > user chooses to disable it with the added 'sve=off' cpu property.
> > Also give the user the ability to select vector lengths with the
> > sve<N> properties. We don't adopt 'max' cpu's other sve property,
> > sve-max-vq, because that property is difficult to use with KVM.
> > That property assumes all vector lengths in the range from 1 up
> > to and including the specified maximum length are supported, but
> > there may be optional lengths not supported by the host in that
> > range. With KVM one must be more specific when enabling vector
> > lengths.
> 
> Hi; I've been looking at the '-cpu max' vs '-cpu host' code
> as part of trying to sort out the 'hvf' accelerator doing
> oddly different things with them. I noticed an oddity
> introduced in this patch. In the commit message you say that
> we deliberately leave the 'sve-max-vq' property out of the
> new aarch64_add_sve_properties(), because it is difficult to
> use with KVM. But in the code for handling '-cpu max' in
> aarch64_max_initfn():
> 
> > @@ -602,17 +617,11 @@ static void cpu_arm_set_sve(Object *obj, Visitor *v, const char *name,
> >  static void aarch64_max_initfn(Object *obj)
> >  {
> >      ARMCPU *cpu = ARM_CPU(obj);
> > -    uint32_t vq;
> > -    uint64_t t;
> >
> >      if (kvm_enabled()) {
> >          kvm_arm_set_cpu_features_from_host(cpu);
> > -        if (kvm_arm_sve_supported(CPU(cpu))) {
> > -            t = cpu->isar.id_aa64pfr0;
> > -            t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
> > -            cpu->isar.id_aa64pfr0 = t;
> > -        }
> 
> because this 'if' doesn't exit the function early...
> 
> >      } else {
> > +        uint64_t t;
> >          uint32_t u;
> >          aarch64_a57_initfn(obj);
> >
> > @@ -712,17 +721,9 @@ static void aarch64_max_initfn(Object *obj)
> >  #endif
> >      }
> 
> ...all this code at the tail of the function runs for both KVM
> and TCG, and it still sets the sve-max-vq property, even for
> using '-cpu max' with KVM.
> 
> > -    object_property_add(obj, "sve", "bool", cpu_arm_get_sve,
> > -                        cpu_arm_set_sve, NULL, NULL, &error_fatal);
> > +    aarch64_add_sve_properties(obj);
> >      object_property_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_max_vq,
> >                          cpu_max_set_sve_max_vq, NULL, NULL, &error_fatal);
> > -
> > -    for (vq = 1; vq <= ARM_MAX_VQ; ++vq) {
> > -        char name[8];
> > -        sprintf(name, "sve%d", vq * 128);
> > -        object_property_add(obj, name, "bool", cpu_arm_get_sve_vq,
> > -                            cpu_arm_set_sve_vq, NULL, NULL, &error_fatal);
> > -    }
> >  }
> 
> Was this intentional?

No, darn. I don't know how many times I rebased that series and was always
careful to ensure sve-max-vq was left in the non-kvm part of the above
condition. I guess the final rebase finally got me...

> 
> I'd like to fix up the weird divergence between -cpu host and
> -cpu max, either by moving sve-max-vq into aarch64_add_sve_properties()
> so it's present on both, or by changing the aarch64_max_initfn() so
> it only adds the property when using TCG.

The later, please. sve-max-vq won't work for any of the machines that
support SVE that I know of, so I think it's a bad idea for KVM.

> 
> (I think also this code may get the '-cpu max,aarch64=off' case wrong,
> as it doesn't guard the calls to add the sve and pauth properties
> with the "if aarch64" feature check.)

Yes, but these property dependencies may need to be checked at property
finalize time. That means that the properties may get added, but then
they will error out if the user tried to enable them. Otherwise, they'll
be disabled and the QMP query will inform the user that they cannot be
enabled.

Thanks,
drew



  reply	other threads:[~2022-02-03 18:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-01  8:51 [PULL 00/11] target-arm queue Peter Maydell
2019-11-01  8:51 ` [PULL 01/11] target/arm/monitor: Introduce qmp_query_cpu_model_expansion Peter Maydell
2019-11-01  8:51 ` [PULL 02/11] tests: arm: Introduce cpu feature tests Peter Maydell
2019-11-01  8:51 ` [PULL 03/11] target/arm: Allow SVE to be disabled via a CPU property Peter Maydell
2019-11-01  8:51 ` [PULL 04/11] target/arm/cpu64: max cpu: Introduce sve<N> properties Peter Maydell
2019-11-12 10:23   ` Peter Maydell
2019-11-13 20:17     ` Richard Henderson
2019-11-13 21:30       ` Peter Maydell
2019-11-15  8:29         ` Richard Henderson
2019-11-01  8:51 ` [PULL 05/11] target/arm/kvm64: Add kvm_arch_get/put_sve Peter Maydell
2019-11-01  8:51 ` [PULL 06/11] target/arm/kvm64: max cpu: Enable SVE when available Peter Maydell
2019-11-01  8:51 ` [PULL 07/11] target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features Peter Maydell
2019-11-01  8:51 ` [PULL 08/11] target/arm/cpu64: max cpu: Support sve properties with KVM Peter Maydell
2019-11-01  8:51 ` [PULL 09/11] target/arm/kvm: host cpu: Add support for sve<N> properties Peter Maydell
2022-02-03 16:46   ` Peter Maydell
2022-02-03 17:36     ` Andrew Jones [this message]
2022-02-03 17:40       ` Peter Maydell
2022-02-04 11:26         ` Andrew Jones
2019-11-01  8:51 ` [PULL 10/11] hw/arm/boot: Rebuild hflags when modifying CPUState at boot Peter Maydell
2019-11-01  8:51 ` [PULL 11/11] target/arm: Allow reading flags from FPSCR for M-profile Peter Maydell
2019-11-01  9:30 ` [PULL 00/11] target-arm queue Peter Maydell
2019-11-01  9:54   ` Andrew Jones
2019-11-01 10:34     ` Peter Maydell
2019-11-01 12:53       ` Peter Maydell
2019-11-01 14:25         ` Andrew Jones
2019-11-02 17:57           ` Peter Maydell

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=20220203173640.shxkmatdcsfzzvtj@gator \
    --to=drjones@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).