Magenheimer, Dan (HP Labs Fort Collins)
2005-May-01 03:43 UTC
[Xen-devel] RE: [Xen-ia64-devel] machine ITM = nearest guest ITM vs. full guesttime virtualization
Moving to xen-ia64-devel...> -----Original Message----- > From: xen-ia64-devel-bounces@lists.xensource.com > [mailto:xen-ia64-devel-bounces@lists.xensource.com] On Behalf > Of Dong, Eddie > Sent: Saturday, April 30, 2005 2:47 AM > To: xen-ia64-devel@lists.xensource.com > Cc: xen-devel > Subject: [Xen-ia64-devel] machine ITM = nearest guest ITM vs. > full guesttime virtualization > > 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@lists.xensource.com > http://lists.xensource.com/xen-ia64-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel