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
