[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] RE: TSC scaling and softtsc reprise, and PROPOSAL
Dan Magenheimer wrote:
>>> Can someone at Intel confirm or deny that VMware ESX
>>> always traps rdtsc? If so, it is probably not hard
>>> to write an application that works on VMware ESX (on
>>> certain hardware) but fails on Xen.
>> I'd be rather surprised if VMware trapped RDTSC. From what I
>> gather, ESX3 doesn't make a great deal of use of VT for 32b
>> guests, so at the very least it would be tricky to do
>> anything about user space use of rdtsc.
> Some googling and reading provides evidence that VMware
> does indeed virtualize the TSC. The timekeeping paper
> tells how to turn vTSC off, but says that turning it
> off is no longer recommended. The ASPLOS paper
> uses rdtsc as an example of how binary translation
> is much faster than emulation or callout (though
> their BT version fetches a stale TSC which afaict
> doesn't solve the ordering problem).
> Also, Avi Kivity tells me that the KVM folks have
> also recently come to the conclusion that it is necessary
> to emulate TSC, though KVM currently does not.
I am still confused about why need to emulate rdtsc is necessary. Even if
emulating it in software, we still need to find a stable time source, right?
If you think TSC is not stable on SMP system, and I think the issue should
exist in native OS which depends on TSC as time source instead of Xen-self
issue. If host's TSC is stable enough, I think the hardware's TSC offset
feature should be the right way to go ?
I have a proposal on it. If Xen finds hardware's TSC is not reliable, it can
tell guest about the info at guest's boot stage, and guest should use other
time sources(eg, hpet) instead of TSC . And if the TSC is reliable in hardware,
I think we should let Xen try the best to use hardware's feature and just leave
it as current implementation. If users know hardware's TSC is not reliable from
his knowledge, it may set softtsc to solve the possible issue manually. So
maybe we only need to create a way how to tell guest the TSC's status in Xen
Xen-devel mailing list