* Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote: > > Your implementation is almost the perfect prototype, if you move the > > 128 bit hackery into the hypervisor and hide it away from the kernel > > :) > > The point is to use the tsc to avoid making any hypercalls, so dealing > with the tsc->ns conversion has to happen on the guest side somehow. 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'. I'd expect hypercalls to be put into silicon just as much as SYSENTER was put into silicon. 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'. The TSC is awfully unreliable. really, it's a bit as if Linus looked at his 386DX CPU when he bought it 16 years ago and decided that: "this CPU executes 16-bit code much faster than 32-bit code, so lets base this new toy OS on 16-bit code. Sure, it's a bit of a pain to use, compared to 32-bit code, but users demand performance!". /THIS/ is the kind of junk we are trying to protect Linux against. Basically hypervisors are a way to prolong hardware legacies, and because unlike real hardware software ABIs dont actually burn out with time, and people are stubborn about using them, their effects are alot worse and alot longer than that of legacy hardware. Ingo _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
