Ingo Molnar wrote:
> you are obsessed with avoiding a hypercall, but why? Granted it's slow
> especially on things like SVN/VMX, but it's not fundamentally slow. We
> definitely do not want to design our whole APIs and abstractions around
> the temporary notion that 'hypercalls are slow'.
Sure. But the specific case we're talking about here is a 300 line
clock driver. Nothing about its implementation has any effect on the
kernel's APIs or abstractions.
> I'd expect hypercalls
> to be put into silicon just as much as SYSENTER was put into silicon.
>
Sysenter is marginally faster than int $80, but not massively so. I
guess Xen could use sysenter now for hypercalls, since its only useful
for getting into ring 0.
> Anyway, in terms of guest time code, a /big/ amount of design junk can
> be avoided by not trying to do sillynesses like 'virtual time'.
Well, if you have a hypervisor scheduler multiplexing vcpus onto a real
cpu at 100hz and a kernel scheduler multiplexing processes onto a vcpu
at 100hz, then you're going to get a lot of disappointed processes who
nominally got their 10ms real-time slice, but it was all spent on some
other vcpu. Its important that the kernel's scheduler know how much
vcpu time each process really got, rather than basing its scheduling on
the amount of real time that passed.
> The TSC
> is awfully unreliable.
>
Sure.
> /THIS/ is the kind of junk we are trying to protect Linux against.
>
What? That Xen happens to use the tsc as part of its hypervisor
interface? A fact that's completely isolated from the rest of the
kernel behind the clock subsystem?
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/virtualization
