All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Andrew Jones <drjones@redhat.com>
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 17:40:20 +0000	[thread overview]
Message-ID: <CAFEAcA9_3DNozRsH8+iXbs2Z4-ar=Eki3ENvZocSmfbp+g13qQ@mail.gmail.com> (raw)
In-Reply-To: <20220203173640.shxkmatdcsfzzvtj@gator>

On Thu, 3 Feb 2022 at 17:36, Andrew Jones <drjones@redhat.com> wrote:
>
> On Thu, Feb 03, 2022 at 04:46:21PM +0000, Peter Maydell wrote:
> > 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.

Does 'max' need to do anything different from what we're doing
already in arm_host_initfn() for 'host' ? (My proposal for
fixing this stuff is basically to make aarch64_max_initfn()
start with "if (kvm or hvf) { call arm_host_initfn(); return }".)

thanks
-- PMM


  reply	other threads:[~2022-02-03 18:27 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
2022-02-03 17:40       ` Peter Maydell [this message]
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='CAFEAcA9_3DNozRsH8+iXbs2Z4-ar=Eki3ENvZocSmfbp+g13qQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=drjones@redhat.com \
    --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 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.