On Wed, 25 May 2022 at 16:07, Laszlo Ersek <lersek(a)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.)
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.
Ah, so that's my big misunderstanding -- I didn't realize it was *just*
a QOM property. I thought it caused a guest-visible VCPU feature to
appear, only on "max" (with KVM).
If that's not the case, then my concern is gone.
Thanks!
Laszlo