On 09/17/09 12:45, Dan Magenheimer wrote:
> Well, as I've said all along, a driver in a dynamically loadable
> module is OK. Whether sensible or not, customers don't seem to
> care about that, they only care if you change the kernel bits
> that gets loaded.
>
A loadable driver wouldn't be able to claim fixmap slots or anything
like that, but, yes, it could present an mmapable device.
>> Once you're making kernel changes then you can update the pvclock
>> mechanism to use the xen clock algorithm, obviating the need for
>> usermode ABI changes.
>>
> Is that working yet (fast vsyscall under Xen)? >:-)
>
It's just a matter of someone spending some time on it. My frustration
with the pvtsc scheme is that its incredibly niche and is only going to
serve a very small number of users; a similar amount of effort spent on
a vsyscall solution will have a much larger payoff.
>> However, if its really the case that the tsc is guaranteed
>> synchronized,
>> then the guest can determine that for itself by looking at
>> cpuid and/or
>> /proc/cpuinfo (and presumably doing some sanity checking) and
>> then just
>> directly use rdtsc, with no need to change either Xen or the kernel.
>>
> That's exactly what the app is doing when on bare metal.
>
Sure. And they still need to deal with discontinuities resulting from
suspend/resume on bare-metal, so dealing with discontinuities caused by
migration is no different. And on bare metal it would need to compute
the tsc frequency for itself, so it doesn't really need Xen support for
that either.
> But in virtual unless it gets some kind of notification on
> migration (which would be cool, but would also require
> kernel changes?), it can't determine the appropriate
> scaling factor and offset, or that they need to change.
>
Well, they have access to xenbus, so they could get the tsc parameters
that way, along with notifications about changes. It wouldn't be
completely synchronous, but you'd need to implement the pvclock
algorithm to do that. But as I say, it has to cope with all this on
bare metal anyway, so it doesn't really need anything from Xen.
> (The userland pvclock algorithm would need to keep
> a version indicator just like the kernel pvclock does.)
> So that's what the userland-accessible shared page
> is needed for.
>
Sure. The mechanism is the same as you'd need to do vsyscall.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home