[Xen-ia64-devel] machine ITM = nearest guest ITM vs. full guest time virtualization

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Dan:
        For the guest time (vtimer) implementation, the current approach
is to set machine ITM to the nearest guest ITM ( HV next ITM) and set
machine ITC to guest ITC. Yes it may have benefits when the guest domain
# is small, but how about my full virtualization suggestion?
        1: Each VP keeps an internal data structure that including at
least vITM and an offset for guest ITC to machine ITC. This offset is
updated when guest set ITC. (Thus guest ITC = machine ITC + offset)
        2: Each time when guest set ITM with guest ITC < guest ITM and
vITV is enabled, we add a vtime_ac_timer for notification.
        3: When this vtime_ac_time is due, the callback function will
call vcpu_pend_interrupt to pend vTimer IRQ.
        4: In this way the machine ITC/ITM is fully used by HV. 
        5: When this VP is scheduled out, the vtime_ac_time should be
removed to reduce the ac_timer link length and improve scalability.
        6: When the VP is scheduled in, VMM will check if it is due, if
it is due during deschedule time, inject guest timer IRQ. If it is not,
re-add the vtime_ac_timer.

        Pros for current implementation:
        1: Guest timer fired at much accurate time.

        Cons:
        1: Serious scalability issue. If there are 16 VMs running with
each VM has 4 VPs. The current implementation will see 64 times more HV
timer IRQs.
        2: If domain-N set ITC, I am afraid current implementation is
hard to handle.
        3: HV jiffies is hard to track including stime_irq,
get_time_delta() and XEN common macro NOW().

        Pros for full guest time virtualization:
        1: Good scalability. Each LP only see one vtime_ac_time pending
in the ac_time link no matter how many VMs exist.
        2: Seamless for domain0 and domain N.

        Cons:
        1: It may fire a little bit later than the exactly expected
time.



        This approach can also be used for X86 lsapic timer.
Eddie


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel