> On 08/23/09 09:42, Dan Magenheimer wrote:
> > While I'm hoping that this is true, I am skeptical. The
> > PV time algorithm does depend on TSC accuracy for interpolating
> > over short intervals doesn't it?
>
> Yes, it extrapolates, assuming that in the absence of power
> events, etc,
> the tsc is stable over a period of a few seconds on a given CPU.
A lot can happen in a few seconds...
> > does the SMP PV guest maintain time properly?
>
> It uses timing parameters from Xen.
> If Xen can't keep track of the tsc
> and events which affect it and provides bad info, it will fail.
Let's assume that Xen CAN keep track.
How does the PV guest know if Xen's timing parameters change?
Is it required to remember Xen's timing parameters from the last
time it checked and compare them with this time?
> The ABI never
> assumes that the tsc is synchronized between CPUs, or that they're
> running at even approximately the same rate.
This is a shame, given that it IS synchronized between CPUs
and they ARE running at exactly the same rate on the vast majority
of future (single-socket multi-core) systems. Especially given that the
alternative is one-to-three orders of magnitude slower.
> The main risk is having the CPU asynchronously change speed under Xen,
> with either no notification or a delayed notification (like thermal
> events). Any synchronous speed change can be dealt with.
I guess I need to understand this better.
> > And even if it does, this doesn't help applications that read
> > TSC directly (which, admittedly, they shouldn't, but since
> > the processor vendors have made TSC much "safer" on most
> > systems, which will probably soon account for >90% of systems
> > shipped, SMP app direct use of TSC will likely become more
> prevalent.)
>
> Right. That's basically not supported under Linux, except as part of
> certain ABIs like vgettimeofday (which is functionally
> identical to the
> Xen PV clock ABI).
Again, a shame. I'm learning that it is not uncommon for unprivileged
code to sample "time" tens of thousands or even hundreds of thousands
of times per processor per second. Trapping all app rdtscs or Linux
going to HPET or PIT just doesn't cut it if the frequency is
this high. If TSC is "safe" 99.99% of the time, it sure would
be nice if those apps could use rdtsc.
I'm trying to find a solution that allows this to be supported
in a virtual environment (without huge loss of performance).
And I think I might have one.
> > It's dom0. I do see get an IP but it varies pretty widely from
> > sample (of '0') to sample and I haven't tried a symbol lookup
> > yet because I fear they will be buried in layers of block drivers
> >
> > I'm still hoping for some clue without digging that deep...
> > All I've presumably done (assuming my patch doesn't have a weird
> > bug) is make rdtsc slower.
>
> It's presumed to be fast in a number of places, but it shouldn't cause
> it to fail. Maybe some race is coming up. If you just revert the
> register write to make rdtsc trap, does it still hang?
I just got a big clue... the next line of console output in a
successful boot AFTER the EXT3-fs mounting message is from
the Real Time Clock Driver. That sounds like something that
might be affected by rdtsc changes.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home