[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 22.09.09 01:29 >>> > >Yes, I neglected an important pre-condition. ASSUME the first > >rdtscp on pcpu-A gets a version mismatch so that it must fetch > >the parameters again. Then: the vcpu switches pcpu TWICE > >from pcpu-A to pcpu-B and back to pcpu-A and does rdtscp > >each time on pcpu-A but reads one or more pvclock parameters > >(that are too big to be encoded in TSC_AUX) on pcpu-B. > > This fundamentally depends on how the pvclock parameters are being > read: While app-accessible MSRs inherently require each of > the necessary > RDMSRs to be executed on the correct {p,v}CPU (unless you encode the > CPU number in the RDMSR input), an app accessible shared memory region > wouldn't have that property. Hmmm... I think a shared memory region still does have that property. To avoid any possibility of a race, there must be a way to atomically fetch the full set of values: { tsc, tsc_aux, pvclock parameters }. (How many bits total in pvclock parameters?) Jeremy's proposal of a userland hypercall ("get_new_pvclock_info") can do that, but I don't see how a shared memory region can. But a userland hypercall that writes to userland memory seems risky. An app can mmap memory, if it fails to do so (either accidentally or maliciously), bad things can happen, correct? Pardon my x86 ignorance again: If we define a userland rdmsr, it could overwrite more than just EDX:EAX. If it overwrites all registers that can safely be changed by the calling convention, which registers (how many bits) can it "return"? I suspect this isn't enough for 32-bit guests, but maybe it is for 64-bit guests? Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |