Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
>> Anthony Liguori wrote:
>>
>>> Okay. I may remove this patch from the patch series and attempt to
>>> sit down next week and work out something more complete that also
>>> implements stolen time accounting.
>>>
>>
>> Well, that's a separate problem. clocksource.read should always return
>> real time passed, so stolen time doesn't come into it.
>
> Right.
>
>>
>> paravirt_ops.sched_clock should take stolen time into account, but
>> that's almost completely orthogonal.
>>
>
> 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.
> 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. 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.
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
