[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |