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

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

[Gavin Shan]

This standardizes kvm exit reason field name by replacing "esr_ec"
with "exit_reason".

Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 virt/kvm/arm/trace.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
index 204d210d01c2..0ac774fd324d 100644
--- a/virt/kvm/arm/trace.h
+++ b/virt/kvm/arm/trace.h
@@ -27,25 +27,27 @@ TRACE_EVENT(kvm_entry,
 );
 
 TRACE_EVENT(kvm_exit,
-	TP_PROTO(int ret, unsigned int esr_ec, unsigned long vcpu_pc),
-	TP_ARGS(ret, esr_ec, vcpu_pc),
+	TP_PROTO(int ret, unsigned int exit_reason, unsigned long vcpu_pc),
+	TP_ARGS(ret, exit_reason, vcpu_pc),
 
 	TP_STRUCT__entry(
 		__field(	int,		ret		)
-		__field(	unsigned int,	esr_ec		)
+		__field(	unsigned int,	exit_reason	)
 		__field(	unsigned long,	vcpu_pc		)
 	),
 
 	TP_fast_assign(
 		__entry->ret			= ARM_EXCEPTION_CODE(ret);
-		__entry->esr_ec = ARM_EXCEPTION_IS_TRAP(ret) ? esr_ec : 0;
+		__entry->exit_reason =
+			ARM_EXCEPTION_IS_TRAP(ret) ? exit_reason: 0;
 		__entry->vcpu_pc		= vcpu_pc;
 	),
 
 	TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
 		  __print_symbolic(__entry->ret, kvm_arm_exception_type),
-		  __entry->esr_ec,
-		  __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
+		  __entry->exit_reason,
+		  __print_symbolic(__entry->exit_reason,
+				   kvm_arm_exception_class),
 		  __entry->vcpu_pc)
 );
 
-- 
2.23.0

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

[Marc Zyngier]

Hi Gavin,

On 2019-12-12 02:45, Gavin Shan wrote:
> This standardizes kvm exit reason field name by replacing "esr_ec"
> with "exit_reason".
>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
>  virt/kvm/arm/trace.h | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
> index 204d210d01c2..0ac774fd324d 100644
> --- a/virt/kvm/arm/trace.h
> +++ b/virt/kvm/arm/trace.h
> @@ -27,25 +27,27 @@ TRACE_EVENT(kvm_entry,
>  );
>
>  TRACE_EVENT(kvm_exit,
> -	TP_PROTO(int ret, unsigned int esr_ec, unsigned long vcpu_pc),
> -	TP_ARGS(ret, esr_ec, vcpu_pc),
> +	TP_PROTO(int ret, unsigned int exit_reason, unsigned long vcpu_pc),
> +	TP_ARGS(ret, exit_reason, vcpu_pc),
>
>  	TP_STRUCT__entry(
>  		__field(	int,		ret		)
> -		__field(	unsigned int,	esr_ec		)
> +		__field(	unsigned int,	exit_reason	)

I don't think the two are the same thing. The exit reason should be
exactly that: why has the guest exited (exception, host interrupt, 
trap).

What we're reporting here is the exception class, which doesn't apply 
to
interrupts, for example (hence the 0 down below, which we treat as a
catch-all).

>  		__field(	unsigned long,	vcpu_pc		)
>  	),
>
>  	TP_fast_assign(
>  		__entry->ret			= ARM_EXCEPTION_CODE(ret);
> -		__entry->esr_ec = ARM_EXCEPTION_IS_TRAP(ret) ? esr_ec : 0;
> +		__entry->exit_reason =
> +			ARM_EXCEPTION_IS_TRAP(ret) ? exit_reason: 0;
>  		__entry->vcpu_pc		= vcpu_pc;
>  	),
>
>  	TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
>  		  __print_symbolic(__entry->ret, kvm_arm_exception_type),
> -		  __entry->esr_ec,
> -		  __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
> +		  __entry->exit_reason,
> +		  __print_symbolic(__entry->exit_reason,
> +				   kvm_arm_exception_class),
>  		  __entry->vcpu_pc)
>  );

The last thing is whether such a change is an ABI change or not. I've 
been very
reluctant to change any of this for that reason.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

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

[Gavin Shan]

On 12/12/19 8:23 PM, Marc Zyngier wrote:
> On 2019-12-12 02:45, Gavin Shan wrote:
>> This standardizes kvm exit reason field name by replacing "esr_ec"
>> with "exit_reason".
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>>  virt/kvm/arm/trace.h | 14 ++++++++------
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
>> index 204d210d01c2..0ac774fd324d 100644
>> --- a/virt/kvm/arm/trace.h
>> +++ b/virt/kvm/arm/trace.h
>> @@ -27,25 +27,27 @@ TRACE_EVENT(kvm_entry,
>>  );
>>
>>  TRACE_EVENT(kvm_exit,
>> -    TP_PROTO(int ret, unsigned int esr_ec, unsigned long vcpu_pc),
>> -    TP_ARGS(ret, esr_ec, vcpu_pc),
>> +    TP_PROTO(int ret, unsigned int exit_reason, unsigned long vcpu_pc),
>> +    TP_ARGS(ret, exit_reason, vcpu_pc),
>>
>>      TP_STRUCT__entry(
>>          __field(    int,        ret        )
>> -        __field(    unsigned int,    esr_ec        )
>> +        __field(    unsigned int,    exit_reason    )
> 
> I don't think the two are the same thing. The exit reason should be
> exactly that: why has the guest exited (exception, host interrupt, trap).
> 
> What we're reporting here is the exception class, which doesn't apply to
> interrupts, for example (hence the 0 down below, which we treat as a
> catch-all).
> 

Marc, thanks a lot for your reply. Yeah, the combination (ret and esr_ec) is
complete to indicate the exit reasons if I'm understanding correctly.

The exit reasons seen by kvm_stat is exactly the ESR_EL1[EC]. It's declared
by marcro AARCH64_EXIT_REASONS in tools/kvm/kvm_stat/kvm_stat. So it's precise
and complete from perspective of kvm_stat.

For the patch itself, it standardizes the filter name by renaming "esr_ec"
to "exit_reason", no functional changes introduced and I think it would be
fine.

>>          __field(    unsigned long,    vcpu_pc        )
>>      ),
>>
>>      TP_fast_assign(
>>          __entry->ret            = ARM_EXCEPTION_CODE(ret);
>> -        __entry->esr_ec = ARM_EXCEPTION_IS_TRAP(ret) ? esr_ec : 0;
>> +        __entry->exit_reason =
>> +            ARM_EXCEPTION_IS_TRAP(ret) ? exit_reason: 0;
>>          __entry->vcpu_pc        = vcpu_pc;
>>      ),
>>
>>      TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
>>            __print_symbolic(__entry->ret, kvm_arm_exception_type),
>> -          __entry->esr_ec,
>> -          __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
>> +          __entry->exit_reason,
>> +          __print_symbolic(__entry->exit_reason,
>> +                   kvm_arm_exception_class),
>>            __entry->vcpu_pc)
>>  );
> 
> The last thing is whether such a change is an ABI change or not. I've been very
> reluctant to change any of this for that reason.
> 

Yeah, I think it is ABI change unfortunately, but I'm not sure how many applications
are using this filter. However, the fixed filter name ("exit_reason") is beneficial
in long run. The application needn't distinguish architects to provide different
tracepoint filters at least.

Regards,
Gavin

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

[Marc Zyngier]

Hi Gavin,

On 2019-12-13 00:50, Gavin Shan wrote:
> On 12/12/19 8:23 PM, Marc Zyngier wrote:
>> On 2019-12-12 02:45, Gavin Shan wrote:
>>> This standardizes kvm exit reason field name by replacing "esr_ec"
>>> with "exit_reason".
>>>
>>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>>> ---
>>>  virt/kvm/arm/trace.h | 14 ++++++++------
>>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
>>> index 204d210d01c2..0ac774fd324d 100644
>>> --- a/virt/kvm/arm/trace.h
>>> +++ b/virt/kvm/arm/trace.h
>>> @@ -27,25 +27,27 @@ TRACE_EVENT(kvm_entry,
>>>  );
>>>
>>>  TRACE_EVENT(kvm_exit,
>>> -    TP_PROTO(int ret, unsigned int esr_ec, unsigned long vcpu_pc),
>>> -    TP_ARGS(ret, esr_ec, vcpu_pc),
>>> +    TP_PROTO(int ret, unsigned int exit_reason, unsigned long 
>>> vcpu_pc),
>>> +    TP_ARGS(ret, exit_reason, vcpu_pc),
>>>
>>>      TP_STRUCT__entry(
>>>          __field(    int,        ret        )
>>> -        __field(    unsigned int,    esr_ec        )
>>> +        __field(    unsigned int,    exit_reason    )
>> I don't think the two are the same thing. The exit reason should be
>> exactly that: why has the guest exited (exception, host interrupt, 
>> trap).
>> What we're reporting here is the exception class, which doesn't 
>> apply to
>> interrupts, for example (hence the 0 down below, which we treat as a
>> catch-all).
>>
>
> Marc, thanks a lot for your reply. Yeah, the combination (ret and 
> esr_ec) is
> complete to indicate the exit reasons if I'm understanding correctly.
>
> The exit reasons seen by kvm_stat is exactly the ESR_EL1[EC]. It's 
> declared
> by marcro AARCH64_EXIT_REASONS in tools/kvm/kvm_stat/kvm_stat. So
> it's precise
> and complete from perspective of kvm_stat.
>
> For the patch itself, it standardizes the filter name by renaming 
> "esr_ec"
> to "exit_reason", no functional changes introduced and I think it 
> would be
> fine.

It may not be a functional change, but it is a semantic change. To me,
'exit_reason' means something, and esr_ec something entirely different.

But the real blocker is below.

>>>          __field(    unsigned long,    vcpu_pc        )
>>>      ),
>>>
>>>      TP_fast_assign(
>>>          __entry->ret            = ARM_EXCEPTION_CODE(ret);
>>> -        __entry->esr_ec = ARM_EXCEPTION_IS_TRAP(ret) ? esr_ec : 0;
>>> +        __entry->exit_reason =
>>> +            ARM_EXCEPTION_IS_TRAP(ret) ? exit_reason: 0;
>>>          __entry->vcpu_pc        = vcpu_pc;
>>>      ),
>>>
>>>      TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
>>>            __print_symbolic(__entry->ret, kvm_arm_exception_type),
>>> -          __entry->esr_ec,
>>> -          __print_symbolic(__entry->esr_ec, 
>>> kvm_arm_exception_class),
>>> +          __entry->exit_reason,
>>> +          __print_symbolic(__entry->exit_reason,
>>> +                   kvm_arm_exception_class),
>>>            __entry->vcpu_pc)
>>>  );
>> The last thing is whether such a change is an ABI change or not. 
>> I've been very
>> reluctant to change any of this for that reason.
>>
>
> 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.

> However, the fixed filter name ("exit_reason") is beneficial in long 
> run.
> The application needn't distinguish architects to provide different
> tracepoint filters at least.

Well, you certainly need to understand the actual semantic behind the
fields if you want to draw any meaningful conclusion. Otherwise, all
you need is to measure the frequency of such event.

         M.
-- 
Jazz is not dead. It just smells funny...

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

[Gavin Shan]

On 12/13/19 8:47 PM, Marc Zyngier wrote:
> On 2019-12-13 00:50, Gavin Shan wrote:
>> On 12/12/19 8:23 PM, Marc Zyngier wrote:
>>> On 2019-12-12 02:45, Gavin Shan wrote:
>>>> This standardizes kvm exit reason field name by replacing "esr_ec"
>>>> with "exit_reason".
>>>>
>>>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>>>> ---
>>>>  virt/kvm/arm/trace.h | 14 ++++++++------
>>>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
>>>> index 204d210d01c2..0ac774fd324d 100644
>>>> --- a/virt/kvm/arm/trace.h
>>>> +++ b/virt/kvm/arm/trace.h
>>>> @@ -27,25 +27,27 @@ TRACE_EVENT(kvm_entry,
>>>>  );
>>>>
>>>>  TRACE_EVENT(kvm_exit,
>>>> -    TP_PROTO(int ret, unsigned int esr_ec, unsigned long vcpu_pc),
>>>> -    TP_ARGS(ret, esr_ec, vcpu_pc),
>>>> +    TP_PROTO(int ret, unsigned int exit_reason, unsigned long vcpu_pc),
>>>> +    TP_ARGS(ret, exit_reason, vcpu_pc),
>>>>
>>>>      TP_STRUCT__entry(
>>>>          __field(    int,        ret        )
>>>> -        __field(    unsigned int,    esr_ec        )
>>>> +        __field(    unsigned int,    exit_reason    )
>>> I don't think the two are the same thing. The exit reason should be
>>> exactly that: why has the guest exited (exception, host interrupt, trap).
>>> What we're reporting here is the exception class, which doesn't apply to
>>> interrupts, for example (hence the 0 down below, which we treat as a
>>> catch-all).
>>>
>>
>> Marc, thanks a lot for your reply. Yeah, the combination (ret and esr_ec) is
>> complete to indicate the exit reasons if I'm understanding correctly.
>>
>> The exit reasons seen by kvm_stat is exactly the ESR_EL1[EC]. It's declared
>> by marcro AARCH64_EXIT_REASONS in tools/kvm/kvm_stat/kvm_stat. So
>> it's precise
>> and complete from perspective of kvm_stat.
>>
>> For the patch itself, it standardizes the filter name by renaming "esr_ec"
>> to "exit_reason", no functional changes introduced and I think it would be
>> fine.
> 
> It may not be a functional change, but it is a semantic change. To me,
> 'exit_reason' means something, and esr_ec something entirely different.
> 
> But the real blocker is below.
> 

Agree.

>>>>          __field(    unsigned long,    vcpu_pc        )
>>>>      ),
>>>>
>>>>      TP_fast_assign(
>>>>          __entry->ret            = ARM_EXCEPTION_CODE(ret);
>>>> -        __entry->esr_ec = ARM_EXCEPTION_IS_TRAP(ret) ? esr_ec : 0;
>>>> +        __entry->exit_reason =
>>>> +            ARM_EXCEPTION_IS_TRAP(ret) ? exit_reason: 0;
>>>>          __entry->vcpu_pc        = vcpu_pc;
>>>>      ),
>>>>
>>>>      TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
>>>>            __print_symbolic(__entry->ret, kvm_arm_exception_type),
>>>> -          __entry->esr_ec,
>>>> -          __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
>>>> +          __entry->exit_reason,
>>>> +          __print_symbolic(__entry->exit_reason,
>>>> +                   kvm_arm_exception_class),
>>>>            __entry->vcpu_pc)
>>>>  );
>>> The last thing is whether such a change is an ABI change or not. I've been very
>>> reluctant to change any of this for that reason.
>>>
>>
>> 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.
> 

Ah, it's not good :)

>> However, the fixed filter name ("exit_reason") is beneficial in long run.
>> The application needn't distinguish architects to provide different
>> tracepoint filters at least.
> 
> Well, you certainly need to understand the actual semantic behind the
> fields if you want to draw any meaningful conclusion. Otherwise, all
> you need is to measure the frequency of such event.
> 

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?

Thanks,
Gavin

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

[Vitaly Kuznetsov]

Gavin Shan <gshan@redhat.com> 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). 

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.

-- 
Vitaly

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

[Marc Zyngier]

On 2019-12-16 09:14, Vitaly Kuznetsov wrote:
> Gavin Shan <gshan@redhat.com> 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...

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

[Gavin Shan]

On 12/16/19 8:35 PM, Marc Zyngier wrote:
> On 2019-12-16 09:14, Vitaly Kuznetsov wrote:
>> Gavin Shan <gshan@redhat.com> 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/
>

The extension means to add a new field "exit_reason" for aarch64. We can't
delete or rename the existing fields in order to keep the compatibility.
Also, the newly added field ("exit_reason") will carry duplicated information
that have been carried by "ret" and "esr_ec". I guess it's going to make the
interface ugly. So I personally prefer to fix the issue from "kvm_stat" and
I'm going to post a v2 patch for this shortly.

Thanks again to Vitaly and Marc for your comments :)

Regards,
Gavin

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

[Paolo Bonzini]

On 16/12/19 10:14, Vitaly Kuznetsov wrote:
>> 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). 

I'd agree with that, plus trace-cmd since it has a KVM plugin,
especially since KVM has for example debugfs stats unlike other
subsystems (and we're tracing debugfs stats as stable userspace API, and
planning to move them somewhere out of debugfs).  But I wouldn't
complain either if architecture maintainers feel differently.

Paolo

> 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.