Am 12.09.2013 um 20:31 schrieb Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>: > On Fri, 2013-09-13 at 10:17 +1000, Paul Mackerras wrote: > >> Aneesh and I are currently investigating an alternative approach, >> which is much more like the x86 way of doing things. We are looking >> at splitting the code into three modules: a kvm_pr.ko module with the >> PR-specific bits, a kvm_hv.ko module with the HV-specific bits, and a >> core kvm.ko module with the generic bits (basically book3s.c, >> powerpc.c, stuff from virt/kvm/, plus the stuff that both PR and HV >> use). Basically the core module would have a pointer to a struct >> full of function pointers for the various ops that book3s_pr.c and >> book3s_hv.c both provide. You would only be able to have one of >> kvm_pr and kvm_hv loaded at any one time. If they were built in, you >> could have them both built in but only one could register its function >> pointer struct with the core. Obviously the kvm_hv module would only >> load and register its struct on a machine that had hypervisor mode >> available. If they were both built in I would think we would give HV >> the first chance to register itself, and let PR register if we can't >> do HV. >> >> How does that sound? > > As long as we can force-load the PR one on a machine that normally runs > HV for the sake of testing ... > > Also, all those KVM modules ... they don't auto-load do they ? They don't today, but they should. Alex > > Cheers, > Ben. > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
