![]() | |||||||||||
Messages in this thread |
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 > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2007-09-14 23:49 [from the cache] ©2003-2008 | |||||||||||