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 ? 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
