On Thu, Aug 29, 2013 at 12:56:40AM +0200, Alexander Graf wrote: > > On 06.08.2013, at 06:18, Paul Mackerras wrote: > > > #ifdef CONFIG_PPC_BOOK3S_64 > > - /* default to book3s_64 (970fx) */ > > + /* > > + * Default to the same as the host if we're on a POWER7[+], > > + * otherwise default to PPC970FX. > > + */ > > vcpu->arch.pvr = 0x3C0301; > > + if (cpu_has_feature(CPU_FTR_ARCH_206)) > > + vcpu->arch.pvr = mfspr(SPRN_PVR); > > Unrelated change? Also, why? Any reasonable user space these days should set PVR anyways. The issue is that the most widely-deployed userspace user of KVM (i.e., QEMU) does the KVM_PPC_GET_SMMU_INFO ioctl *before* it tells KVM what it wants the guest PVR to be. Originally I had kvm_vm_ioctl_get_smmu_info() returning the 64k page size only if the BOOK3S_HFLAG_MULTI_PGSIZE flag was set, so I had to add this change so that userspace would see the 64k page size. So yes, I could probably remove this hunk now. > > > > + /* 64k large page size */ > > + info->sps[2].page_shift = 16; > > + info->sps[2].slb_enc = SLB_VSID_L | SLB_VSID_LP_01; > > + info->sps[2].enc[0].page_shift = 16; > > + info->sps[2].enc[0].pte_enc = 1; > > We only support this with BOOK3S_HFLAG_MULTI_PGSIZE, no? The virtual machine implemented by PR KVM supports 64k pages on any hardware, since it is implementing the POWER MMU in software. That's why I didn't make it depend on that flag. That means that we rely on userspace to filter out any capabilities that don't apply to the machine it wants to emulate. We can't do that filtering here because userspace queries the MMU capabilities before it sets the PVR. Regards, Paul. -- 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
