From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH 19/23] KVM: PPC: Book3S: Select PR vs HV separately for each guest Date: Fri, 13 Sep 2013 11:31:58 +1000 Message-ID: <1379035918.4098.27.camel@pasglop> References: <20130806041259.GF19254@iris.ozlabs.ibm.com> <20130806042628.GY19254@iris.ozlabs.ibm.com> <2E17A7F9-C96F-4372-91D1-18D1753EFB32@suse.de> <20130913001708.GB7113@iris.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Paul Mackerras Return-path: In-Reply-To: <20130913001708.GB7113@iris.ozlabs.ibm.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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.