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

Laszlo Ersek lersek at redhat.com
Thu May 26 08:34:56 UTC 2022


On 05/26/22 10:10, 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.

My concern was not about command line compatibility (libguestfs doesn't
tend to pack the command line with lots of nifty properties); instead I
thought there was a guest ABI difference between these two VCPU types on
KVM. Peter says (IIUC) that there never has been one, so that's good.

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

Yes, I think this is the case with libguestfs's appliance (for aarch64
anyway): it does not provide additional CPU properties (that I know of).

Thanks!
Laszlo

> 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.
> 
> Thanks,
> drew
> 



More information about the Libguestfs mailing list