>>> On 15.11.18 at 22:47, <[email protected]> wrote:
> As noted in c/s 4999bf3e8b "x86/PV: use generic emulator for privileged
> instruction handling", these hoops are jumped through to retain the older
> behaviour, along with a note suggesting that we should reconsider things.
>
> It does not matter exactly when pv_soft_rdtsc() is called, as Xen's behaviour
> is an opaque atomic action from the guests point of view. Furthermore, even
> with PVRDTSCP mode, the TSC_AUX value constant while the domain is
> executing.
Not exactly: I've tried to reconstruct the reasons for the comment you
refer to, and I think it was twofold: For one I wanted to keep the actual
RDTSC as close to the point where the guest actually gets to use the
value as possible. And then from an abstract pov the split between two
MSR accesses means that either can fail, yet pv_soft_rdtsc() back at
the time wrote to the guest RCX directly. That second reason is gone
as of 5b04262079 ("x86/time: Rework pv_soft_rdtsc() to aid further
cleanup"), and the first is presumably not overly relevant, so ...
> Drop all the deferral logic, and leave TSC_AUX uniformly at 0 as PVRDTSCP mode
> is being removed. Later changes will make this behave architecturally.
>
> Signed-off-by: Andrew Cooper <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Jan
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
