Am 15.09.2013 um 04:16 schrieb "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx>: > Alexander Graf <agraf@xxxxxxx> writes: > >> Am 14.09.2013 um 13:33 schrieb "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx>: >> >>> Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> 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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
