From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: Re: [PATCH 19/23] KVM: PPC: Book3S: Select PR vs HV separately for each guest Date: Wed, 18 Sep 2013 22:05:13 +1000 Message-ID: <20130918120513.GA9372@iris.ozlabs.ibm.com> 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=us-ascii Cc: Benjamin Herrenschmidt , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: Alexander Graf Return-path: Content-Disposition: inline In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, Sep 12, 2013 at 11:17:11PM -0500, Alexander Graf wrote: > > It means you can only choose between HV and PR machine wide, while with this patch set you give the user the flexibility to have HV and PR guests run in parallel. > > I know that Anthony doesn't believe it's a valid use case, but I like the flexible solution better. It does however male sense to enable a sysadmin to remove any PR functionality from the system by blocking that module. > > Can't we have both? So, one suggestion (from Aneesh) is to use the 'type' argument to kvm_arch_init_vm() to indicate whether we want a specific type of KVM (PR or HV), or just the default. Zero would mean default (fastest available) whereas other values would indicate a specific choice of PR or HV. Then, if we build separate kvm_pr and kvm_hv modules when KVM is configured to be a module, the sysadmin can control the default choice by loading and unloading modules. How does that sound? Or would you prefer to stick with a single module and have a module option to control the default choice? Paul.