Re: [PATCH 2/2] kvm: Add ioctl for gathering debug counters

[Alexander Graf <graf@amazon.de>]

On 23.01.20 15:50, Paolo Bonzini wrote:
> On 23/01/20 15:45, Alexander Graf wrote:
>> I think we're in agreement then, just leaning onto the other side of the
>> same fence. My take is that if I don't know whether a string is
>> necessary, I'd rather not have a string :).
> 
> And for me it's if I don't know whether a #define is necessary, I'd
> rather not have a #define.  So yeah we agree on everything except the
> userspace API (which is no small thing, but it's a start).
> 
>> I guess as long as we do get stat information out per-vm as well as
>> per-vcpu through vmfd and vcpufd, I'm happy overall.
>>
>> So how strongly do you feel about the string based approach?
> 
> I like it, of course.
> 
>> PS: You could btw easily add a "give me the string for a ONE_REG id"
>> interface in KVM to translate from 0x10042 to "insn_emulation_fail" :).
> 
> That could actually be somewhat useful for VCPU registers as well (give
> me the string and type, and a list of valid ONE_REG ids).  If that was

You don't need the type explicitly, it's part of the ONE_REG identifier :).

> the case, of course it would be fine for me to use ONE_REG on a VM.  The
> part which I don't like is having to make all ONE_REG part of the
> userspace ABI/API.

We don't have all of ONE_REG as part of the user space ABI today. On 
Book3S PPC you can not access BookE ONE_REG variables for obvious 
reasons. Neither can you access ARM ONE_REGs. Not implementing a ONE_REG 
is perfectly ok.

But I like the idea of a ONE_REG query interface that gives you the list 
of available registers and a string representation of them. It would 
make programming kvm from Python so easy!


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879