[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-ia64-devel] RE: Timer merge
>> This is a bug if you want to keep a periodic HZ concept in
>> hypervisor. (Maybe we can abandon it and only keep a one-shot
>> timer model later). It's unrelated to this discussion, and
>> just raised it since mentioned in the context.
>I'm not sure I understand the differences between the periodic
>HZ concept and the one-shot timer model... doesn't there always
>need to be a timeout for the currently running domain so
>the hypervisor scheduler can schedule a different domain?
Sorry to put confused concept here. What I mean by "one-shot" timer here
actually mean a tick-less model where next interrupt point is always
triggered by closest timer event, without need to care fixed delta.
Current model actually keeps both. Just raise a possibility.
>> IMO, the extra work should at least keep a global monotonic
>> increasing variable to hold itc value at last time interrupt.
>> Then the delta value of guest itc should base on this global
>> variable, instead of local itc. When emulating read_from_itc,
>> we may return by formula like "(now_itc > monotonic_itc) ?
>> (now_itc + vitc_delta) : (monotonic_itc + vitc_delta)". This
>> can promise itc never going backward when vcpu migration. En,
>> anyway this is just some rough thought immediately raised,
>> and we definitely need elaborate and detail discussion in
>> design for vcpu migration. Currently we just need a guest ITM
>> together with ITC delta, as Eddie suggested.
>So in your model, reading itc is privileged? (e.g. secure
>itc bit is on) In the current model, it is not.
Still guest can read itc directly, as long as the global value stamped
in the shared page when injecting guest timer interrupt. Just same as
you need to export itc delta to guest too. Guest shouldn't use itc value
directly, even when it can read.
Xen-ia64-devel mailing list