On 29.08.2013, at 07:17, Paul Mackerras wrote: > 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. Ok, works for me :). 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
