On Wed, Mar 01 2023, Andrea Bolognani <abologna@xxxxxxxxxx> wrote: > On Wed, Mar 01, 2023 at 03:15:17PM +0100, Cornelia Huck wrote: >> On Wed, Mar 01 2023, Andrea Bolognani <abologna@xxxxxxxxxx> wrote: >> > I'm actually a bit confused. The documentation for the mte property >> > of the virt machine type says >> > >> > mte >> > Set on/off to enable/disable emulating a guest CPU which implements >> > the Arm Memory Tagging Extensions. The default is off. >> > >> > So why is there a need to have a CPU property in addition to the >> > existing machine type property? >> >> I think the state prior to my patches is actually a bit confusing: the >> user needs to set a machine type property (causing tag memory to be >> allocated), which in turn enables a cpu feature. Supporting the machine >> type property for KVM does not make much sense IMHO: we don't allocate >> tag memory for KVM (in fact, that would not work). We have to keep the >> previous behaviour, and explicitly instructing QEMU to create cpus with >> a certain feature via a cpu property makes the most sense to me. > > I agree that a CPU feature makes more sense. > >> We might want to tweak the documentation for the machine property to >> indicate that it creates tag memory and only implicitly enables mte but >> is a pre-req for it -- thoughts? > > I wonder if it would be possible to flip things around, so that the > machine property is retained with its existing behavior for backwards > compatibility, but both for KVM and for TCG the CPU property can be > used on its own? > > Basically, keeping the default of machine.mte to off when cpu.mte is > not specified, but switching it to on when it is. This way, you'd be > able to simply use > > -machine virt -cpu xxx,mte=on > > to enable MTE, regardless of whether you're using KVM or TCG, instead > of requiring the above for KVM and > > -machine virt,mte=on -cpu xxx > > for TCG. The machine prop is a bool; that means that we cannot distinguish between "user did not set mte at all" and "user explicitly set mte=off" -- I think we want -machine virt,mte=off -cpu xxx,mte=on to generate an error, but that would still imply that we'd need to error out for -machine virt -cpu xxx,mte=on as well. We could make the machine prop OnOffAuto, but that looks like overkill to me. > > Note that, from libvirt's point of view, there's no advantage to > doing things that way instead of what you already have. Handling the > additional machine property is a complete non-issue. But it would > make things nicer for people running QEMU directly, I think. I'm tempted to simply consider this to be another wart of the QEMU command line :)
