[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] machine ITM = nearest guest ITM vs. full guesttime virtualization
> > Yes, that's the difference. I use ac_timer only for > > scheduling (ITC==XenITM). I don't even need to use it > > there but it is convenient for interfacing to the Xen > > scheduling code. > Yes it can work, but we are deviating from X86 XEN more. Any > strategy in deviation from X86? I think this deviation is not > necessary. The timer mechanisms are sufficiently different between X86 and ia64 (and other architectures) that it may make sense for ac_timer.c to be moved to archdep code. > > So, yes, when switching from domainA to domainB, if a significant > > amount of time has transpired since domainB ran, it's highly > > likely that the first instruction that will be executed by > > domainB will be in the IVT at the interrupt vector to handle > > a clock tick. > The problem is how you know domain B transpired a significant > amount of time without extra data structure? I mean HV needs > to track last guest ITC and ITM to know there is condition > for timer IRQ to fire. If you would like to track the last > guest ITC, the design will be much like same. Maybe you can > give more comments after you saw the code. If you think of the "Xen ITC" as the official ITC, domain switch from A to B requires adding the offset of domainA to return to Xen ITC, then subtracting the offset of domainB to obtain domainB's ITC. I think this works and is very simple... but as I said, this hasn't been tested because Linux doesn't do it. _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |