Re: [PATCH 1/8] qmp: Support for querying stats

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 5/5/22 15:28, Markus Armbruster wrote:
>> Double-checking (pardon my ignorance): we're basically exposing the host
>> kernel's KVM stats via QMP, with the option of extending it to other
>> sources of stats in the future.  Correct?
>
> Yes.  As long as KVM is the only source, it's basically an opaque 1:1
> mapping of what the kernel gives.

I'd like this to be captured in documentation and / or a commit message,
because ...

>> I think the argument for accepting the interface is basically "if it's
>> good enough for the kernel, it's good enough for us".  Valid point.
>
> Also, it was designed from the beginning to be extensible to other
> _kernel_ subsystems as well; i.e. it's not virt-specific in any way.
>
> There is one important point: theoretically, stats names are not part
> of the kernel API.  In practice, you know what the chief penguin
> thinks of breaking userspace and anyway I don't think any of the stats
> have ever been removed when they were in debugfs (which makes them
> even less of a stable API).
>
> For a similar situation see https://lwn.net/Articles/737530/: kernel
> developers hate that tracepoints are part of the stable API, but in 
> practice they are (and stats are much harder to break than
> tracepoints, if it's worth exposing them to userspace in the first
> place).
>
>> This means we'll acquire yet another introspection system, unrelated to
>> the introspection systems we already have in QEMU.

... ^^^ needs justification.  Explain why passing the kernel's
existing interface through QEMU is useful, and to whom.

>> There is overlap.  Quite a few query- commands return stats.  Should
>> they be redone as statistics provides in this new introspection system?
>
> I think so, potentially all of them can be moved.  Whether it is worth
> doing it is another story.
>
> In addition, query-stats provides a home for TCG statistics that
> currently QMP exposes only via x- commands; they can be added without 
> having to design the whole QAPI thing, and with a slightly less strong
> guarantee of stability.

How strong do we feel about the stability of the stats exposed by this
command?  Separate answers for *structure* of the stats and concrete
stats.

If we're confident neither structure nor concrete stats will change
incompatibly, the commands are stable without reservations.

If we're confident the structure is stable, but unable or unwilling to
commit to the concrete stats, we should explain this in documentation.

If we're unsure about both, the commands should be marked unstable.  We
can always upgrade stability later.

[...]