On Tue, Mar 19, 2024 at 03:00:40PM +0000, Peter Maydell wrote: > On Tue, 19 Mar 2024 at 14:57, Eric Auger <eauger@xxxxxxxxxx> wrote: > > > > Hi Peter, > > > > On 2/29/24 12:00, Peter Maydell wrote: > > > > > > It doesn't appear because the list of properties that we advertise > > > via query-cpu-model-expansion is set in the cpu_model_advertised_features[] > > > array in target/arm/arm-qmp-cmds.c, and this patch doesn't add > > > 'kvm-pmu-filter' to it. But you have a good point about all the > > > others being bool properties: I don't know enough about that > > > mechanism to know if simply adding this to the list is right. > > > > > > This does raise a more general question: do we need to advertise > > > the existence of this property to libvirt via QMP? Eric, Sebastian: > > > do you know ? > > sorry I missed this question. yes I think it is sensible to expose that > > option to libvirt. There is no good default value to be set at qemu > > level so to me it really depends on the upper stack to choose the > > correct value (depending on the sensitiveness of the data that justified > > the kernel uapi). > > In that case we should definitely have a mechanism for libvirt > to be able to say "does this QEMU (and this CPU) implement > this property?". Unfortunately my QMP/libvirt expertise is > too low to be able to suggest what that mechanism should be... Libvirt uses 'qom-list' on '/machine/unattached/device[0]' to identify CPU properties. If 'kvm-pmu-filter' appears with that, then detection will be fine. 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 :|
