On 12/14/2010 05:32 PM, Anthony Liguori wrote:
> If anything I'd expect hpet or the Microsoft synthetic timers to
be a
> lot more important.
True. But also a lot more work.
Implementing just the pm timer counter - not the whole of it - in
kernel, gives us a lot of gain with not very much effort. Patch is
pretty simple, as you can see, and most of it is even code to turn it
on/off, etc.
Partial emulation is not something I like since it causes a fuzzy
kernel/user boundary. In this case, transitioning to userspace when
interrupts are enabled doesn't look so hot. Are you sure all guests
that benefit from this don't enable the pmtimer interrupt? What
about the transition? Will we have a time discontinuity when that
happens?
What I'd really like to see is this stuff implemented in bytecode,
unfortunately that's a lot of work which will be very hard to upstream.
Fortunately, we have a very good bytecode interpreter that's
accelerated in the kernel called KVM ;-)
We have exactly the same bytecode interpreter under a different name,
it's called userspace.
If you can afford to make the transition back to the guest for
emulation, you might as well transition to userspace.
Why not have the equivalent of a paravirtual SMM mode where we can
reflect IO exits back to the guest in a well defined way? It could
then implement PM timer in terms of HPET or something like that.
More exits.
We already have a virtual address space that works for most guests
thanks to the TPR optimization.
It only works for Windows XP and Windows XP with the /3GB extension.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
