On 23.01.20 15:19, Paolo Bonzini wrote:
On 23/01/20 13:32, Alexander Graf wrote:
See above: I am not sure they are the same story because their consumers
might be very different from registers. Registers are generally
consumed by programs (to migrate VMs, for example) and only occasionally
by humans, while stats are meant to be consumed by humans. We may
disagree on whether this justifies a completely different API...
I don't fully agree on the "human" part here.
I agree it's not entirely about humans, but in general it's going to be
rules and queries on monitoring tools, where 1) the monitoring tools'
output is generally not KVM-specific, 2) the rules and queries will be
written by humans.
So if the kernel produces insn_emulation_fail, the plugin for the
monitoring tool will just log kvm.insn_emulation_fail. If the kernel
produces 0x10042, the plugin will have to convert it and then log it.
This is why I'm not sure that providing strings is actually less work
for userspace.
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 :).
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?
Alex
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" :).
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
