Re: [Qemu-devel] [PATCHv18/8] trace: [tcg] Add per-vCPU tracing states for events with the 'vcpu' property

[Lluís Vilanova]

Eric Blake writes:

> On 10/13/2015 11:11 AM, Lluís Vilanova wrote:
[...]
>> +##
>> +{ 'command': 'trace-event-get-cpu-state',
>> +  'data': {'name': 'str', 'vcpu': 'int'},
>> +  'returns': ['TraceEventInfo'] }
>> +
>> +##
>> +# @trace-event-set-cpu-state:
>> +#
>> +# Set the dynamic state of events in a given vCPU.
>> +#
>> +# @name: Event name pattern.
>> +# @vcpu: The vCPU to act upon.
>> +# @enable: Whether to enable tracing.
>> +# @ignore-unavailable: #optional Do not match unavailable events with @name.
>> +#
>> +# Since 2.2

> 2.5, not 2.2

Old patches :)

>> +##
>> +{ 'command': 'trace-event-set-cpu-state',
>> +  'data': {'name': 'str', 'vcpu': 'int', 'enable': 'bool', 
>> '*ignore-unavailable': 'bool'} }

> This looks identical to trace-event-set-state, except that it now has a
> 'vcpu':'int' argument.  Would it be any simpler to just modify the
> existing command:

> ##
> # @trace-event-set-state:
> ...
> # @vcpu: #optional If provided, limit the state change to the given vcpu
> (default act on all vcpus) (since 2.5)
> #
> # Since 2.2
> ##
>  { 'command': 'trace-event-set-state',
>    'data': {'name': 'str', 'enable': 'bool',
>             '*vcpu': 'int', '*ignore-unavailable': 'bool'} }

Hmmm, this certainly minimizes the interface size, but in exchange breaks the
symmetry between trace-event-get-state/trace-event-set-state and
trace-event-get-cpu-state/trace-event-set-cpu-state, and the symmetry between
these commands and the function inside QEMU (this last one probably not very
important).

What I could do is also merge trace-event-get-state and
trace-event-get-cpu-state into a single command with an optional cpu.

This reminds me that the meaning of "get-state" for per-vCPU events is somewhat
tricky in the current implementation. There's a per-event boolean with the
system-wide tracing state, and a per-cpu-and-event boolean for the per-CPU
tracing state. The get/set-event functions let you interact with type of
booleans separately.

If anyone sees it useful, I can make it a bit easier to understand: if no CPU
number is provided, get-state returns true if it's set on any CPU, and set-state
sets the state on all CPUs by default.


Thanks,
  Lluis

-- 
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth