Am 15.09.2013 um 04:16 schrieb "Aneesh Kumar K.V" <[email protected]>:
> 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. Heh ok :). I think we want to be flexible here unless complexity grows too much of a maintenance burden and/or slows things down. Alex > > -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
