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. Alex -- 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
