> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 25.11.09 22:24 >>>
> >Xen intentionally does not expose the cpuid rdtscp bit
> >to PV OS's or to HVM guests, but PV apps can see this
> >bit and, as a result, may choose to use the rdtscp
> >instruction. When a PV guest with such an app is migrated
> >to a machine that does not have rdtscp support, the
> >app will get killed due to an invalid op. Fix this
> >by emulating the rdtscp instruction. We also need
> >to emulate rdtscp in the case where the machine has
> >rdtscp support, but rdtsc emulation is enabled (which
> >is unfortunately a different path: a privileged op).
>
> I realize that my comment really applies to your earlier
> patch introducing
> rdtsc emulation, but somehow that aspect slipped my attention back
> then: Linux has, as a security option, a mechanism to disable
> rdtsc for
> apps, but your emulation code doesn't honor the guest setting of
> CR4.TSD.
Hi Jan --
I suppose it's a moot point since Keir has patched it already
anyway, but what is the mechanism for Linux to do this?
Have you tried it on SuSE or any recent distro lately?
Does Linux emulate rdtsc then (and, if so, could you point
me to the code in the kernel that does it)?
I ask because I found that the dynamic loader uses rdtsc
(harmlessly) so if CR4.TSD is turned off by Linux and
Linux doesn't emulate rdtsc, I suspect turning on this
security option is suicidal.
Thanks,
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|