[Libguestfs] [PATCH] always 'max' for the appliance CPU model on all targes except ppc

Richard W.M. Jones rjones at redhat.com
Wed May 25 17:34:44 UTC 2022


On Wed, May 25, 2022 at 05:13:53PM +0100, Peter Maydell wrote:
> On Wed, 25 May 2022 at 16:07, Laszlo Ersek <lersek at redhat.com> wrote:
> >
> > + Drew & Peter
> >
> > On 05/25/22 15:30, Daniel P. Berrangé wrote:
> > - The patch seems to do what it says in the commit message.
> >
> > - QEMU commit bab52d4bba3f ("target/arm: Add "-cpu max" support",
> >   2018-03-09) confirms what the commit message says, about both TCG and
> >   KVM.
> >
> > - To smoke-test the TCG-related change, I've edited a long-term TCG
> >   aarch64 libvirt domain of mine, replacing "cortex-a57" with "max".
> >   Both edk2 and the Linux guest continued working. So I guess the TCG
> >   change is OK.
> 
> One thing to note here is that if you are using:
>  * TCG -cpu max
>  * 'virt' with no named version or with 'virt-7.0' or later
>  * a Linux kernel version prior to v5.12
> then a bug in Linux means it won't boot. (This is because of
> the LPA2 CPU feature which TCG -cpu max now emulates; older
> kernels were buggy and won't boot on an LPA2 CPU, including
> a real hardware one.)

Is this related at all to the 5-level page tables (la57) failure with
TCG and -cpu max?

https://gitlab.com/qemu-project/qemu/-/issues/1023

Rich.

> You might or might not feel this is something worth noting in
> release notes or equivalent.
> 
> 
> > - In additional support of the above, QEMU commit ddaebdda53fc
> >   ("target/arm: Unindent unnecessary else-clause", 2022-02-21) added a
> >   comment saying
> >
> >   /* '-cpu max' for TCG: we currently do this as "A57 with extra things" */
> >
> > - Although I was more surprised by the TCG-related statement initially
> >   (i.e. that "max" was a superset of "cortex-a57" when using TCG), now
> >   I'm actually more concerned about the KVM case.
> 
> The TCG part is an implementation convenience (mostly it just
> means that 'max' has the A57's IMPDEF registers).
> 
> >   Specifically QEMU commit 0baa21be497d ("target/arm: Make KVM -cpu max
> >   exactly like -cpu host", 2022-02-21) eliminated a difference where
> >   "-cpu max" had been a superset of "-cpu host", featuring the
> >   "sve-max-vq" extra property.
> >
> >   The fix is part of release v7.0.0.
> >
> >   The difference was introduced in commits
> >
> >   [1] 6fa8a37949d9 ("target/arm/cpu64: max cpu: Support sve properties
> >       with KVM", 2019-11-01)
> >
> >   [2] 87014c6b3660 ("target/arm/kvm: host cpu: Add support for sve<N>
> >       properties", 2019-11-01)
> >
> >   and apparently *deliberately*.
> 
> No, this was unintentional. See the discussion in this thread:
> https://lore.kernel.org/qemu-devel/20220203173640.shxkmatdcsfzzvtj@gator/
> 
> In particular, although KVM '-cpu max' had the sve-max-vq
> property, Drew notes "sve-max-vq won't work for any of the machines that
> support SVE that I know of". Which is why we removed it, rather
> than adding it to '-cpu host'.
> 
> >   Therefore it seems that starting with qemu-4.2, but strictly preceding
> >   qemu-7.0, "-cpu max" and "-cpu host" are not "identical" when KVM is
> >   enabled; "-cpu max" has more features. Because of that, I think there
> >   are two options:
> >
> >   (a) This extra feature is actually harmless, so we should only update
> >       the commit message (i.e., generally speaking, "-cpu max" has been
> >       a superset of "-cpu host" on KVM and of "-cpu cortex-a57" on TCG).
> >
> >   (b) The feature actually presents a problem, and qemu in [v4.2.0,
> >       v7.0.0) will not start when KVM accel and "-cpu max" are requested
> >       simultaneously. In this case, I think the appliance needs to stick
> >       with "-cpu host" on KVM.
> 
> I don't understand why you think these are the only two options. The
> actual situation is:
> 
>  (c) -cpu max and -cpu host have always been identical on KVM,
>  and this commit does not change that.
>  There happens to have been a QOM property 'sve-max-vq' on 'max'
>  that should not have existed there and that nobody can actually have
>  been usefully setting, but now there isn't.
> 
> thanks
> -- PMM
> 
> _______________________________________________
> Libguestfs mailing list
> Libguestfs at redhat.com
> https://listman.redhat.com/mailman/listinfo/libguestfs

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html


More information about the Libguestfs mailing list