[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [Patch] time resolution fix.
On 17 Mar 2006, at 16:11, Dong, Eddie wrote:
I have a much detail description in the attached slide, hope this helpful.
Well, freezing the TSC while a guest is descheduled is not very nice at all, but I can imagine it stops you getting time went backwards messages if you are also forcibly re-setting the TSC on PIT ticks. :-)
The freezing is I guess why you have the new hook schedule_out(), which I'm also not madly keen on. Especially since this must surely be a short-term workaround (you don't intend to TSC freeze as long-term solution, right?).
BTW, due to SMP support and more time resource support (RTC and ACPI), we are planning to do some design modification to sync all those different kind of time. This patch is mainly for bug fix that exist for long time and block SMP effort.
Clearly some effort needs to be applied here. Moving all time emulation into Xen itself would be a good start (e.g., strip PIT emulation from qemu-dm).
And the new support should be HVM generic, since there are no differences in time handling between VMX and SVM that should require (much) vendor-specific handling I think. If there are, or extra vendor support appears in future (e.g., I'd like to see guest TSC rate control, as I've said a few times before ;-) ), then we can add vendor hooks in later.
In summary, I'm not sure about this patch. I feel that if I take it I'm encouraging 'onward and upward' development without spending the time to make sure fundamental abstractions like time are designed and implemented soundly.
-- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our