Jeremy Fitzhardinge wrote: >> I'm starting to lean toward just using 0000. If for no other reason >> than the hypercall space is unsharable. >> > > Well, it could be, but it would take affirmative action on the guest's > part. If there's feature bits for each supported hypercall interface, > then you could have a magic MSR to select which interface you want to > use now. That would allow a generic-interface-using guest to probe for > the generic interface at cpuid leaf 0x40001000, use 40001001 to > determine whether the hypercall interface is available, 4000100x to find > the base of the magic msrs, and write appropriate msr to set the desired > hypercall style (and all this can be done without using vmcall, so it > doesn't matter that hypercall interface is initially established). >
The main thing keeping me from doing this ATM is what I perceive as lack of interest in a generic interface. I think it's also a little premature given that we don't have any features on the plate yet. However, I don't think that means that we cannot turn KVM's PV into a generic one. So here's what I propose. Let's start building the KVM PV interface on 4000 0000. That means that Xen cannot initially use it but that's okay. Once KVM-lite is merged and we have some solid features (and other guests start implementing them), we can also advertise this interface as a "generic interface" by also supporting the signature on leave 4000 1000 and using the MSR trickery that you propose. As long as we all agree not to use 4000 1000 for now, it leaves open the possibility of having a generic interface in the future. 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 > > ------------------------------------------------------------------------- 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
