| Message ID | 20220223223137.114264-1-richard.henderson@linaro.org |
|---|---|
| Headers | show |
| Series | target/arm: Implement LVA, LPA, LPA2 features | expand |
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
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
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
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
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
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(-)