> -----Original Message----- > From: Jan Kiszka [mailto:jan.kiszka@xxxxxx] > Sent: Sunday, November 04, 2012 8:55 PM > To: Hao, Xudong > Cc: qemu-devel@xxxxxxxxxx; avi@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical > address space > > On 2012-11-04 13:15, Hao, Xudong wrote: > >> -----Original Message----- > >> From: Jan Kiszka [mailto:jan.kiszka@xxxxxx] > >> Sent: Saturday, November 03, 2012 6:55 PM > >> To: Hao, Xudong > >> Cc: qemu-devel@xxxxxxxxxx; avi@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx > >> Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical > >> address space > >> > >> On 2012-11-02 06:38, Xudong Hao wrote: > >>> For 64 bit processor, emulate 40 bits physical address if the host physical > >>> address space >= 40bits, else guest physical is same as host. > >>> > >>> Signed-off-by: Xudong Hao <xudong.hao@xxxxxxxxx> > >>> --- > >>> target-i386/cpu.c | 5 ++++- > >>> 1 files changed, 4 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c > >>> index 423e009..3a78881 100644 > >>> --- a/target-i386/cpu.c > >>> +++ b/target-i386/cpu.c > >>> @@ -1584,7 +1584,10 @@ void cpu_x86_cpuid(CPUX86State *env, > uint32_t > >> index, uint32_t count, > >>> if (env->cpuid_ext2_features & CPUID_EXT2_LM) { > >>> /* 64 bit processor */ > >>> /* XXX: The physical address space is limited to 42 bits in exec.c. */ > >>> - *eax = 0x00003028; /* 48 bits virtual, 40 bits physical > */ > >>> +/* XXX: 40 bits physical if host physical address space >= 40 bits */ > >>> + uint32_t a, b, c, d; > >>> + host_cpuid(0x80000008, 0, &a, &b, &c, &d); > >>> + *eax = a < 0x00003028 ? a : 0x00003028; > >> > >> This variation will not only affect -cpu host, right? That can create > >> problems when migrating between hosts with different address widths, and > >> then we will need some control knob to adjust what it reported to the guest. > >> > > > > Oh, I did not consider migrating to different platform(addr widths). > > But I think the fixed value 40 bits may cause problem: in VT-d case, when a > host support GAW < 40 bits, and qemu emulate 40 bits guest physical address > space, will bring bug on: > > > > drivers/iommu/intel-iommu.c > > static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain, > > unsigned long pfn, int target_level) > > { > > int addr_width = agaw_to_width(domain->agaw) - VTD_PAGE_SHIFT; > > ... > > BUG_ON(!domain->pgd); > > BUG_ON(addr_width < BITS_PER_LONG && pfn >> addr_width); > > > > Does it mean that buggy or malicious user space can trigger a kernel > bug? Then this must be fixed of course. > Probably yes, when guest RAM is large enough or allocate MMIO to very high address. Jan, I'm not familiar the migration, do you have interest to add the migration part fixing? -- 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
