On 08/23/09 12:26, Dan Magenheimer wrote:
>> 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...
>
That only matters if things happen that Xen doesn't know about. If
something happens that affects the tsc's parameters, it will update them
immediately.
>>> 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?
>
No, they're in the shared info area. It reads them afresh each time it
reads the tsc. The info has a version counter which gets updated when
the info changes so the guest can make sure it has a consistent snapshot
of both the timing parameters and the tsc. The timing parameters for a
given CPU are only ever updated by that CPU, so there's no risk of races
between CPUs.
BTW, kvm presents exactly the same ABI for its guests using pvclock.
See pvclock_clocksource_read().
>> 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.
>
They can, with the gettimeofday vsyscall (= "syscall" which executes
entirely in usermode within a kernel-provided vsyscall page).
You're trying to make rdtsc something it isn't, even in native execution.
rdtsc represents a massive lost opportunity and failure of imagination
on Intel's part; one hopes that they'll eventually redeem themselves
with a new mechanism which does actually have all the properties one
wants - and that mechanism may eventually end up with rdtsc in it
somewhere. But we're not really there yet, and I think trying to make
rdtsc that thing is a quixotic effort.
> 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.
>
Apps can't reliably use a raw rdtsc anyway, without making unwarranted
assumptions about the underlying hardware. Any app which does may work
well on one system, but then mysteriously fail when you move it to the
backup server.
> 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.
>
Ah, yes. It may be doing some calibration thing which never converges
with a slow rdtsc. But that would be pretty obvious from looking at the
eip/rip.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home