Re: [PATCH 3/3] kvm/arm: Standardize kvm exit reason field

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019-12-16 09:14, Vitaly Kuznetsov wrote:
Gavin Shan <gshan@xxxxxxxxxx> writes:

On 12/13/19 8:47 PM, Marc Zyngier wrote:
On 2019-12-13 00:50, Gavin Shan wrote:

Yeah, I think it is ABI change unfortunately, but I'm not sure how
many applications are using this filter.

Nobody can tell. The problem is that someone will write a script that
parses this trace point based on an older kernel release (such as
what the distros are shipping today), and two years from now will
shout at you (and me) for having broken their toy.


Well, I would like to receive Vitaly's comments here. Vitaly, it seems it's more realistic to fix the issue from kvm_stat side according to the comments
given by Marc?


Sure, if we decide to treat tracepoints as ABI then fixing users is
likely the way to go. Personally, I think that we should have certain
freedom with them and consider only tools which live in linux.git when making changes (and changing the tool to match in the same patch series
is OK from this PoV, no need to support all possible versions of the
tool).

So far, the approach has been a pretty conservative one, and there was
countless discussions (including a pretty heated one at KS two years ago,
see [1] which did set the tone for the whole of the discussion).

So as far as I have something to say about this, we're not renaming fields
in existing tracepoints.

Also, we can be a bit more conservative and in this particular case
instead of renaming fields just add 'exit_reason' to all architectures where it's missing. For ARM, 'esr_ec' will then stay with what it is and 'exit_reason' may contain something different (like the information why
the guest exited actually). But I don't know much about ARM specifics
and I'm not sure how feasible the suggestion would be.

It should be possible to /extend/ tracepoints without breaking compatibility, and I don't have any issue with that. This could either report the unmodified 'ret' value, or something more synthetic. It really depends on what you want
this information for.

        M.

[1] https://lwn.net/Articles/737532/
--
Jazz is not dead. It just smells funny...



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux