[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: TSC scaling and softtsc reprise, and PROPOSAL



> >> pre-VT it wasn't possible to trap RDTSC, so this can't 
> help PV guests.
> > 
> > For PV guests, CR4.TSD would always be set, generating
> > a general protection fault for every rdtsc.  (Or perhaps
> > I am missing some x86 architectural subtlety?  This is
> > how it is done on ia64.)
> 
> Forgot about CR4.TSD. Of course it's not going to be a super 
> fast path,
> since #GP(0) will need to be demuxed by decoding the faulting 
> instruction in
> the hypervisor, via a not-so-short path.

And demuxing/decoding can never be "fast enough"?
Even if this particular situation is special-cased?

I'm not saying it will be pretty, or maintainable,
just wondering what the best possible could be?


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.