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. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
