[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
> >> Making vsyscall work... > > > > While I highly respect your opinion, and while vsyscall > > may be a fine choice in the future, it just doesn't > > solve the problem today and won't solve it ever for > > currently shipping PV OS's. If you can figure out a > > way to allow vsyscall to be installed as a module and > > still achieve its performance, it > > might be a possible solution, but otherwise we have > > to go around the OS to solve this problem. > > Do you believe there's a solution which doesn't involve PV kernel > modifications? I think the suggestions you've made so far > would require such modifications. That is certainly my goal. I *think* the proposal does NOT require PV OS mods as the communication is strictly between an app and Xen. However, I'm really not familiar with all the subtleties of the x86 architecture so could be missing something. I think these are the two key architectural dependencies that I'm not certain of: 1) fake rdmsr (or hypercall if it works) returns a virtual address within a range of addresses that is not "owned by" the OS (e.g. maybe in Xen address space?). The page is only readable outside of ring 0, but writeable in ring 0 (by Xen). 2) All TLB misses on this page are handled directly by Xen so the OS never sees the address/page. If these are OK, and you see other parts of the proposal that require PV kernel mods, please point them out. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |