[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v3 00/17] target/arm: Implement LVA, LPA, LPA2 features |
Date: |
Tue, 1 Mar 2022 16:28:26 +0000 |
User-agent: |
Mutt/2.1.5 (2021-12-30) |
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 :|