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

[Daniel P. Berrangé]

On Thu, May 26, 2022 at 10:10:02AM +0200, Andrew Jones wrote:
> 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:
> ...
> > >   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.
> >
> 
> Hi Peter,
> 
> I think I understand Laszlo's concern. If we advertise 'max' as
> effectively being an alias for 'host' when accel=kvm, then we
> should be able to take any given '-cpu max,...' command line
> parameter and replace it with '-cpu host,...' and have it still
> work. That's not the case, at least when sve-max-vq, and I think
> maybe also pauth-impdef, are used.
> 
> Also, if we did want max and host to be aliases for accel=kvm, then
> that implies we need max to work for all '-cpu host,...' with
> accel=tcg as well. And, in that case, we'd need max with TCG to
> "support" kvm-no-adjvtime and kvm-steal-time, which doesn't make
> much sense.
> 
> I think the "solution" is to not infer that max and host are
> effectively aliases allowing seamless transition from tcg to kvm
> and back. One may treat them as aliases when any additional
> properties provided are from the intersection of their supported
> properties, though.
> 
> In summary, if an appliance doesn't provide additional CPU properties
> or it selects only properties that intersect TCG and KVM, then,
> regarding the CPU, when 'max' is used, it can seamlessly change the
> accelerator. Otherwise, while the appliance can leave the CPU as 'max'
> in all cases, it will need to modify selected CPU properties depending
> on the accelerator.

We've never said that 'max' is the same for TCG and KVM, nor do
apps using it require/expect that to be the case.

It is simply intended to expose the maximum featureset available to
any given accelerator backend. On KVM "maximum featureset" is the
same as "host" as you can't expose more than what the hardware has,
while on TCG "maximum featureset" is the most that emulation supports.

The intent is/was that it serves as good CPU choice for apps which
maximises features available, without them needing to think.

Essentially every app should pick 'max' by default unless they need
to restrict features for sake of live migration compatibility, or
need to select a very specific model for some functional reason.

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 :|