Am 12.09.2013 um 19:17 schrieb Paul Mackerras <paulus@xxxxxxxxx>: > On Thu, Sep 12, 2013 at 05:56:11PM -0500, Alexander Graf wrote: >> >> On 05.08.2013, at 23:26, Paul Mackerras wrote: >> >>> This makes it possible to have both PR and HV guests running >>> concurrently on one machine, by deferring the decision about which type >>> of KVM to use for each guest until it either enables the PAPR capability >>> or runs a vcpu. (Of course, this is only possible if both >>> CONFIG_KVM_BOOK3S_PR and CONFIG_KVM_BOOK3S_64_HV are enabled.) >>> >>> Guests start out essentially as PR guests but with kvm->arch.kvm_mode >>> set to KVM_MODE_UNKNOWN. If the guest then enables the KVM_CAP_PPC_PAPR >>> capability, and the machine is capable of running HV guests (i.e. it >>> has suitable CPUs and has a usable hypervisor mode available), the >>> guest gets converted to an HV guest at that point. If userspace runs >>> a vcpu without having enabled the KVM_CAP_PPC_PAPR capability, the >>> guest is confirmed as a PR guest at that point. >>> >>> This also moves the preloading of the FPU for PR guests from >>> kvmppc_set_msr_pr() into kvmppc_handle_exit_pr(), because >>> kvmppc_set_msr_pr() can be called before any vcpu has been run, and >>> it may be that the guest will end up as a HV guest, and in this case >>> the preloading is not appropriate. Instead it is now done after we >>> have emulated a privileged or illegal instruction, if the guest MSR >>> now has FP set. >>> >>> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx> >> >> We need to have a way to force set the mode to either HV, PR or "try HV, fall back to PR if it wouldn't work" (the one you implemented). That way management software can choose to not default to fallback mode if it wants to guarantee consistent performance. > > Yes, Anthony Liguori mentioned a similar concern to me. > > 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? 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? Alex > > Paul. > -- > To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
