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 <ler...@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 > _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs