Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Except that I wanted to change the hypercall to allow querying of real
time or "available" time as VMI puts it.
I see. You could have an interface like Xen's runstate interface, which
gives you a breakdown of how long each vcpu spends in each state
(running, runnable, paused or blocked). The sum of all of them gives
you real time, or you can use a subset to work out stolen time
(runnable+paused), busyness (blocked / (running+runnable+blocked)), etc.
I'll look at that. Since the vmca is per-vcpu, that may work well.
Right now, I'm relying on the PIT but it would be nice to eliminate
that. I'd like to move to something PV so that I can make use of
tickless guest kernels. I'm very open to suggestion and even more
open to reusing other people's code :-)
A simple hypercall interface which says "raise irq X after N ns" is
probably the easiest way to go.
That's what I was thinking. The current bit that makes that ugly is
that you can't really raise an interrupt in the host kernel yet
(although it will be possible when the in-kernel apic code is merged).
I could, in theory, implement that interface in userspace but that may
be ugly.
Try to avoid the pitfalls of VMI's
interface in this area, which tries to recycle existing architectural
interrupt sources for hypervisor timers, and gets into a bit of mess.
Xen is relatively clean, but I'm not sure how it would fit into the
mostly-emulated kvm model. If you keep things simple, most of the Xen
clockevent code could be reused with little change.
I think it should work out well. Thanks for the feedback!
Regards,
Anthony Liguori
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
