On Fri, Aug 17, 2018 at 07:59:40PM +0200, Paolo Bonzini wrote: > On 17/08/2018 19:48, Eduardo Habkost wrote: > > So let's do what's necessary to remove it. But I don't think the > > removal of "feature-words" should block the inclusion of this > > series. > > > > Now, should QOM properties follow our feature deprecation policy, > > or they were never a supported external API and we can remove it > > immediately? > > > > CCing Jiri and libvir-list, because I just found that there's > > code on libvirt that uses it, but I don't know exactly it does > > with that info. > > It is used to check whether the host supports invtsc and pv-unhalt and > avoid changing the guest ABI when migrating: see > https://marc.info/?l=libvir-list&m=152445761414746&w=2 for a patch that > introduces one user. > > I think we should extend it to MSRs, not remove it. Well, I would prefer if libvirt simply did (e.g.) "qom-get property=invtsc" instead of fetching raw feature-words data. But if we do have an existing user, I now agree with you: let's keep it working and extend it to include MSR info too. BTW, libvirt must stop using this hardcoded QOM path: #define QOM_CPU_PATH "/machine/unattached/device[0]" It should use the "qom_path" field of "query-cpus" instead. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
