Re: trace points and ABI

[Avi Kivity <avi@redhat.com>]

On 06/06/2012 03:55 PM, Christian Borntraeger wrote:
> On 24/04/12 14:04, Avi Kivity wrote:
>>> @@ -74,6 +74,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>>>  	{ "instruction_sigp_restart", VCPU_STAT(instruction_sigp_restart) },
>>>  	{ "diagnose_10", VCPU_STAT(diagnose_10) },
>>>  	{ "diagnose_44", VCPU_STAT(diagnose_44) },
>>> +	{ "diagnose_9c", VCPU_STAT(diagnose_9c) },
>>>  	{ NULL }
>>>  };
>>>  
>> 
>> We're switching to tracepoints instead of homebrewed statistics.  It's
>> in feature-removal-schedule.txt already.  It's okay to add them now, but
>> please prepare for their removal.
>> 
> 
> Avi,
> 
> Do you consider these tracepoints itself ABI or not?


I'm not sure what the current kernel dogma is, but I would like to see a
clear separation of architectural tracepoints (=reporting information
defined by the hardware, from the guest point of view; for example an
instruction emulated or a hypercall called) and implementation
tracepoints that record an interesting event, but one that is dependent
on host-side kvm implementation.  Architectural tracepoints would be
soft ABIs (extension is allowed and in extreme cases changes), while
implementation tracepoints are completely fluid.  The current tools are
able to adapt to changes.

x86 kvm once had such a separation, with kvm: tracepoints being
architectural and kvmmmu: tracepoints being implementation defined.
Unfortunately there was some drift (vcpu_match_mmio does not correspond
to an architectural event).

> 
> we are preparing some patches that add trace points in addition to
> a: these stats
> b: our debug feature
> 
> If this is not ABI, then we could work on these trace points step by step,
> e.g. first use the existing stat/debug as trace point places, then combine,
> add or remove  trace points later on if necessary.
> 

I recommend doing the same split.  Architectural tracepoints are easy to
get right, and most useful to a developer.  Implementation tracepoints
are harder to get right, but the cost of getting them wrong is low.  In
any case I'd like to see the entire change in one patchset so we have
all the tracepoints in one kernel release cycle, not several.

-- 
error compiling committee.c: too many arguments to function