Hi,
At 15:38 +0100 on 09 Oct (1255102732), Dan Magenheimer wrote:
> So color me optimistic that the problem is solved or
> at least that system vendors will only sin for a very
> good reason;
OK, we disagree, that's fine.
> Now all I'm trying to do is ensure that Xen virtual machines
> don't suffer their own "d*mn timestamp problem", especially
> given that VMware doesn't have one.
Jeremy seems to be taking care of this, AFAICS, using the existing APIs.
That way everybody wins, not just people who are clued in enough to find
and use a new xen-specific API. Also, AFAICS, without needing changes
to Xen's own timekeeping/TSC code.
There seem to be some other bugs on the HVM side but that's a separate
discussion, I think.
> Yes, I admit it offends my aesthetics some. But I defend
> it to myself by believing that this is just a first step
> in a long road of closer collaboration between hypervisor
> and apps. Really the whole point of paravirtualization
> is to benefit from knowing that the underlying platform
> is virtual. Why should apps be excluded from the party?
In this case I don't think it helps. The OS should and can provide
a fast and reliable time source to user space without needing a new
hypervisor-to-application API for it, with all the portability and
maintenance fun that that would bring.
> I think I've been very explicit: Some very large apps, both
> Oracle and non-Oracle, need a way to get a timestamp
> at a high frequency in a way that is both correct and
> very fast and works across a range of hardware/software
> environments, INCLUDING running under Xen.
There's a further requirement (which you have mentioned before) that
people are unwilling/unable to accept kernel changes. I think that's
a bit unreasonable.
> I AM exposed to some other companies' confidential
> information, so any appearance that I am hiding something
> is due to my clumsy attempts to dance around that
> in a public forum.
Understood; I don't blame you for the situation you find yourself in.
But it doesn't change what you're asking for: an unpleasant hack and a
reshuffle of the core timekeeping code to support unnamed third parties.
> > Might as well call it "application_broken" and default it the other
> > way. :) The system builders are entirely within their rights to have
> > separate clocks for separate sockets.
>
> If you agree with Jeremy's opinion that "any app that uses
> rdtsc is fundamentally broken", your syntax makes sense.
I'll stick with "many apps that use rdtsc are broken": it's harder than
most people think and it doesn't do what some people want. (But no, I
wouldn't seriously use that as the option name.)
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home