Alexander Graf <[email protected]> writes: > Am 14.09.2013 um 13:33 schrieb "Aneesh Kumar K.V" > <[email protected]>: > >> Benjamin Herrenschmidt <[email protected]> writes: >> >>> 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 ... >> >> This is what I currently have >> >> [root@llmp24l02 kvm]# insmod ./kvm-hv.ko >> [root@llmp24l02 kvm]# insmod ./kvm-pr.ko >> insmod: ERROR: could not insert module ./kvm-pr.ko: File exists > > The reason this model makes sense for x86 is that you never have SVM and VMX > in the cpu at the same time. Either it is an AMD chip or an Intel chip. > > PR and HV however are not mutually exclusive in hardware. What you really > want is > > 1) distro can force HV/PR > 2) admin can force HV/PR > 3) user can force HV/PR > 4) by default things "just work" > > 1 can be done through kernel config options. > 2 can be done through modules that get loaded or not > 3 can be done through a vm ioctl > 4 only works if you allow hv and pr to be available at the same time > > I can assume who you talked to about this to make these design decisions, but > it definitely was not me.
I didn't had much discussion around the design with anybody yet. What you saw above was me changing/moving code around madly to get something working in a day. I was hoping to get something that I can post as RFC early and let others to comment. Good to get the feedback early. -aneesh -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
