1. Patchew
  2. QEMU
  3. View series

[PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features

Richard Henderson posted 17 patches 2 years, 2 months ago
Test checkpatch failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220223223137.114264-1-richard.henderson@linaro.org
Maintainers: Peter Maydell <peter.maydell@linaro.org>
There is a newer version of this series
docs/system/arm/emulation.rst |   3 +
include/hw/registerfields.h   |  48 ++++-
target/arm/cpu-param.h        |   4 +-
target/arm/cpu.h              |  27 +++
target/arm/internals.h        |  58 +++---
target/arm/cpu.c              |   3 +-
target/arm/cpu64.c            |   8 +-
target/arm/helper.c           | 332 ++++++++++++++++++++++++++--------
tests/avocado/boot_linux.py   |   4 +-
9 files changed, 384 insertions(+), 103 deletions(-)
[PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
Posted by Richard Henderson 2 years, 2 months ago 
Changes for v3:
  * Update emulation.rst.
  * Split out separate update to ID_AA64MMFR0.
  * Hack for avocado.

If the avocado hack isn't acceptable, perhaps just drop the
last two patches for now?


r~


Richard Henderson (17):
  hw/registerfields: Add FIELD_SEX<N> and FIELD_SDP<N>
  target/arm: Set TCR_EL1.TSZ for user-only
  target/arm: Fault on invalid TCR_ELx.TxSZ
  target/arm: Move arm_pamax out of line
  target/arm: Pass outputsize down to check_s2_mmu_setup
  target/arm: Use MAKE_64BIT_MASK to compute indexmask
  target/arm: Honor TCR_ELx.{I}PS
  target/arm: Prepare DBGBVR and DBGWVR for FEAT_LVA
  target/arm: Implement FEAT_LVA
  target/arm: Implement FEAT_LPA
  target/arm: Extend arm_fi_to_lfsc to level -1
  target/arm: Introduce tlbi_aa64_get_range
  target/arm: Fix TLBIRange.base for 16k and 64k pages
  target/arm: Validate tlbi TG matches translation granule in use
  target/arm: Advertise all page sizes for -cpu max
  tests/avocado: Limit test_virt_tcg_gicv[23] to cortex-a72
  target/arm: Implement FEAT_LPA2

 docs/system/arm/emulation.rst |   3 +
 include/hw/registerfields.h   |  48 ++++-
 target/arm/cpu-param.h        |   4 +-
 target/arm/cpu.h              |  27 +++
 target/arm/internals.h        |  58 +++---
 target/arm/cpu.c              |   3 +-
 target/arm/cpu64.c            |   8 +-
 target/arm/helper.c           | 332 ++++++++++++++++++++++++++--------
 tests/avocado/boot_linux.py   |   4 +-
 9 files changed, 384 insertions(+), 103 deletions(-)

-- 
2.25.1
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
Posted by Peter Maydell 2 years, 1 month ago 
On Wed, 23 Feb 2022 at 22:31, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Changes for v3:
>   * Update emulation.rst.
>   * Split out separate update to ID_AA64MMFR0.
>   * Hack for avocado.
>
> If the avocado hack isn't acceptable, perhaps just drop the
> last two patches for now?

I think that given that there are Linux kernels out there
that won't boot if LPA2 is enabled, we should probably have
a -cpu command line option to disable it. Otherwise we might
get a bunch of "why did my kernel stop booting" bug reports.

thanks
-- PMM
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
Posted by Peter Maydell 2 years, 1 month ago 
On Tue, 1 Mar 2022 at 16:08, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 23 Feb 2022 at 22:31, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > Changes for v3:
> >   * Update emulation.rst.
> >   * Split out separate update to ID_AA64MMFR0.
> >   * Hack for avocado.
> >
> > If the avocado hack isn't acceptable, perhaps just drop the
> > last two patches for now?
>
> I think that given that there are Linux kernels out there
> that won't boot if LPA2 is enabled, we should probably have
> a -cpu command line option to disable it. Otherwise we might
> get a bunch of "why did my kernel stop booting" bug reports.

...and should using a versioned machine type also default
-cpu max to not enabling that? Not sure what x86 or other
precedent is there.

-- PMM
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
Posted by Daniel P. Berrangé 2 years, 1 month ago 
On Tue, Mar 01, 2022 at 04:16:25PM +0000, Peter Maydell wrote:
> On Tue, 1 Mar 2022 at 16:08, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Wed, 23 Feb 2022 at 22:31, Richard Henderson
> > <richard.henderson@linaro.org> wrote:
> > >
> > > Changes for v3:
> > >   * Update emulation.rst.
> > >   * Split out separate update to ID_AA64MMFR0.
> > >   * Hack for avocado.
> > >
> > > If the avocado hack isn't acceptable, perhaps just drop the
> > > last two patches for now?
> >
> > I think that given that there are Linux kernels out there
> > that won't boot if LPA2 is enabled, we should probably have
> > a -cpu command line option to disable it. Otherwise we might
> > get a bunch of "why did my kernel stop booting" bug reports.
> 
> ...and should using a versioned machine type also default
> -cpu max to not enabling that? Not sure what x86 or other
> precedent is there.

I don't recall us coming across an important scenario where a guest
would fail to boot when we /enable/ a given CPU feature on x86,
requiring us to hide it from -cpu max/host.

Assuming the QEMU/KVM implementation of a CPU feature is correct
per the relevant spec, then artificially hiding it by default from
-cpu max feels questionable, as that penalizes non-buggy guest OS.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
Posted by Peter Maydell 2 years, 1 month ago 
On Tue, 1 Mar 2022 at 16:28, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Mar 01, 2022 at 04:16:25PM +0000, Peter Maydell wrote:
> > On Tue, 1 Mar 2022 at 16:08, Peter Maydell <peter.maydell@linaro.org> wrote:
> > >
> > > On Wed, 23 Feb 2022 at 22:31, Richard Henderson
> > > <richard.henderson@linaro.org> wrote:
> > > >
> > > > Changes for v3:
> > > >   * Update emulation.rst.
> > > >   * Split out separate update to ID_AA64MMFR0.
> > > >   * Hack for avocado.
> > > >
> > > > If the avocado hack isn't acceptable, perhaps just drop the
> > > > last two patches for now?
> > >
> > > I think that given that there are Linux kernels out there
> > > that won't boot if LPA2 is enabled, we should probably have
> > > a -cpu command line option to disable it. Otherwise we might
> > > get a bunch of "why did my kernel stop booting" bug reports.
> >
> > ...and should using a versioned machine type also default
> > -cpu max to not enabling that? Not sure what x86 or other
> > precedent is there.
>
> I don't recall us coming across an important scenario where a guest
> would fail to boot when we /enable/ a given CPU feature on x86,
> requiring us to hide it from -cpu max/host.
>
> Assuming the QEMU/KVM implementation of a CPU feature is correct
> per the relevant spec, then artificially hiding it by default from
> -cpu max feels questionable, as that penalizes non-buggy guest OS.

Yeah. It's just unfortunate that "buggy guest OS" here is
"every Linux up to 5.11".

-- PMM
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
Posted by Daniel P. Berrangé 2 years, 1 month ago 
On Tue, Mar 01, 2022 at 04:30:30PM +0000, Peter Maydell wrote:
> On Tue, 1 Mar 2022 at 16:28, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Tue, Mar 01, 2022 at 04:16:25PM +0000, Peter Maydell wrote:
> > > On Tue, 1 Mar 2022 at 16:08, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > >
> > > > On Wed, 23 Feb 2022 at 22:31, Richard Henderson
> > > > <richard.henderson@linaro.org> wrote:
> > > > >
> > > > > Changes for v3:
> > > > >   * Update emulation.rst.
> > > > >   * Split out separate update to ID_AA64MMFR0.
> > > > >   * Hack for avocado.
> > > > >
> > > > > If the avocado hack isn't acceptable, perhaps just drop the
> > > > > last two patches for now?
> > > >
> > > > I think that given that there are Linux kernels out there
> > > > that won't boot if LPA2 is enabled, we should probably have
> > > > a -cpu command line option to disable it. Otherwise we might
> > > > get a bunch of "why did my kernel stop booting" bug reports.
> > >
> > > ...and should using a versioned machine type also default
> > > -cpu max to not enabling that? Not sure what x86 or other
> > > precedent is there.
> >
> > I don't recall us coming across an important scenario where a guest
> > would fail to boot when we /enable/ a given CPU feature on x86,
> > requiring us to hide it from -cpu max/host.
> >
> > Assuming the QEMU/KVM implementation of a CPU feature is correct
> > per the relevant spec, then artificially hiding it by default from
> > -cpu max feels questionable, as that penalizes non-buggy guest OS.
> 
> Yeah. It's just unfortunate that "buggy guest OS" here is
> "every Linux up to 5.11".

Lets say the lpa2 feature was tied so it only gets enabled in the
new 7.0 machine type version, even if KVM/QEMU could supports it
fine with any machine type version. If someone runs a VM with
Linux 5.6 with

  -cpu max -machine virt'

it is going to break.

Our choice is then between telling them to change their QEMU config to

   -cpu max,-lpa2 -machine virt

vs telling them to use

   -cpu max -machine virt-6.2

there's not much practical difference in those scenarios, for someone
deploying a new VM instance.

It would, however, benefit people who had already previously deployed
a VM with QEMU using a explicit versioned machine type. This would
be the case for anyone using libvirt, as libvirt always expands the
user's config to be fully versioned.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.