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