Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > >> The whole point of using the instruction is to allow hypercalls to be >> used in many locations. This has the nice side effect of not >> requiring a central hypercall initialization routine in the guest to >> fetch the hypercall page. A PV driver can be completely independent >> of any other code provided that it restricts itself to it's hypercall >> namespace. >> > > I see. So you take the fault, disassemble the instruction, see that its > another CPU's vmcall instruction, and then replace it with the current > CPU's vmcall? >
Yup. >> Xen is currently using 0/1/2. I had thought it was only using 0/1. >> The intention was not to squash Xen's current CPUID usage so that it >> would still be possible for Xen to make use of the guest code. Can we >> agree that Xen won't squash leaves 3/4 or is it not worth trying to be >> compatible at this point? >> > > No, the point is that you're supposed to work out which hypervisor it is > from the signature in leaf 0, and then the hypervisor can put anything > it wants in the other leaves. > Yeah, see, the initial goal was to make it possible to use the KVM paravirtualizations on other hypervisors. However, I don't think this is really going to be possible in general so maybe it's better to just use leaf 0. I'll let others chime in before sending a new patch. Regards, Anthony Liguori > J > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
