From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space Date: Mon, 05 Nov 2012 07:22:55 +0100 Message-ID: <50975B3F.4070107@web.de> References: <1351834702-25937-1-git-send-email-xudong.hao@intel.com> <5094F7EA.9050200@web.de> <403610A45A2B5242BD291EDAE8B37D300FEFBAF2@SHSMSX102.ccr.corp.intel.com> <50966591.5010903@web.de> <403610A45A2B5242BD291EDAE8B37D300FEFBD6D@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91391D624A05502AC21F801A" Cc: "qemu-devel@nongnu.org" , "avi@redhat.com" , "kvm@vger.kernel.org" , Igor Mammedov , Eduardo Habkost To: "Hao, Xudong" Return-path: Received: from mout.web.de ([212.227.17.12]:64582 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838Ab2KEGXD (ORCPT ); Mon, 5 Nov 2012 01:23:03 -0500 In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEFBD6D@SHSMSX102.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91391D624A05502AC21F801A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-11-05 03:42, Hao, Xudong wrote: >> -----Original Message----- >> From: Jan Kiszka [mailto:jan.kiszka@web.de] >> Sent: Sunday, November 04, 2012 8:55 PM >> To: Hao, Xudong >> Cc: qemu-devel@nongnu.org; avi@redhat.com; kvm@vger.kernel.org >> Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest phys= ical >> address space >> >> On 2012-11-04 13:15, Hao, Xudong wrote: >>>> -----Original Message----- >>>> From: Jan Kiszka [mailto:jan.kiszka@web.de] >>>> Sent: Saturday, November 03, 2012 6:55 PM >>>> To: Hao, Xudong >>>> Cc: qemu-devel@nongnu.org; avi@redhat.com; kvm@vger.kernel.org >>>> Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest ph= ysical >>>> 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 >=3D 40bits, else guest physical is same as host. >>>>> >>>>> Signed-off-by: Xudong Hao >>>>> --- >>>>> 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= =2E */ >>>>> - *eax =3D 0x00003028; /* 48 bits virtual, 40 bits physi= cal >> */ >>>>> +/* XXX: 40 bits physical if host physical address space >=3D 40 bi= ts */ >>>>> + uint32_t a, b, c, d; >>>>> + host_cpuid(0x80000008, 0, &a, &b, &c, &d); >>>>> + *eax =3D a < 0x00003028 ? a : 0x00003028; >>>> >>>> This variation will not only affect -cpu host, right? That can creat= e >>>> problems when migrating between hosts with different address widths,= and >>>> then we will need some control knob to adjust what it reported to th= e 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 ad= dress >> 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 =3D 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 h= igh address. =2E..and those things are under user space control. If you have an idea how to trigger this, please give it a try. This is an availability issue as untrusted user space could bring down the whole system. >=20 > Jan, I'm not familiar the migration, do you have interest to add the mi= gration part fixing? >=20 I'm not up to date with what is going on in the context of CPU feature configuration, CC'ing folks who reworked this recently. In any case, the general pattern is: make this configurable (=3D> CPU feature flag) and then possibly also adjust it for compat QEMU machine types. Jan --------------enig91391D624A05502AC21F801A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCXW0IACgkQitSsb3rl5xSI/wCg0svQiJ2Y/cbQzltVFKkrAU44 0F4AoNFvfq+wOttSA1CUOfejbUcvFFM5 =7eIE -----END PGP SIGNATURE----- --------------enig91391D624A05502AC21F801A-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVG5P-0001yu-Ax for qemu-devel@nongnu.org; Mon, 05 Nov 2012 01:23:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TVG5N-0007Gc-Td for qemu-devel@nongnu.org; Mon, 05 Nov 2012 01:23:03 -0500 Received: from mout.web.de ([212.227.17.12]:58681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVG5N-0007GT-Ju for qemu-devel@nongnu.org; Mon, 05 Nov 2012 01:23:01 -0500 Message-ID: <50975B3F.4070107@web.de> Date: Mon, 05 Nov 2012 07:22:55 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1351834702-25937-1-git-send-email-xudong.hao@intel.com> <5094F7EA.9050200@web.de> <403610A45A2B5242BD291EDAE8B37D300FEFBAF2@SHSMSX102.ccr.corp.intel.com> <50966591.5010903@web.de> <403610A45A2B5242BD291EDAE8B37D300FEFBD6D@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEFBD6D@SHSMSX102.ccr.corp.intel.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91391D624A05502AC21F801A" Subject: Re: [Qemu-devel] [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Hao, Xudong" Cc: Igor Mammedov , Eduardo Habkost , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "avi@redhat.com" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91391D624A05502AC21F801A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-11-05 03:42, Hao, Xudong wrote: >> -----Original Message----- >> From: Jan Kiszka [mailto:jan.kiszka@web.de] >> Sent: Sunday, November 04, 2012 8:55 PM >> To: Hao, Xudong >> Cc: qemu-devel@nongnu.org; avi@redhat.com; kvm@vger.kernel.org >> Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest phys= ical >> address space >> >> On 2012-11-04 13:15, Hao, Xudong wrote: >>>> -----Original Message----- >>>> From: Jan Kiszka [mailto:jan.kiszka@web.de] >>>> Sent: Saturday, November 03, 2012 6:55 PM >>>> To: Hao, Xudong >>>> Cc: qemu-devel@nongnu.org; avi@redhat.com; kvm@vger.kernel.org >>>> Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest ph= ysical >>>> 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 >=3D 40bits, else guest physical is same as host. >>>>> >>>>> Signed-off-by: Xudong Hao >>>>> --- >>>>> 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= =2E */ >>>>> - *eax =3D 0x00003028; /* 48 bits virtual, 40 bits physi= cal >> */ >>>>> +/* XXX: 40 bits physical if host physical address space >=3D 40 bi= ts */ >>>>> + uint32_t a, b, c, d; >>>>> + host_cpuid(0x80000008, 0, &a, &b, &c, &d); >>>>> + *eax =3D a < 0x00003028 ? a : 0x00003028; >>>> >>>> This variation will not only affect -cpu host, right? That can creat= e >>>> problems when migrating between hosts with different address widths,= and >>>> then we will need some control knob to adjust what it reported to th= e 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 ad= dress >> 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 =3D 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 h= igh address. =2E..and those things are under user space control. If you have an idea how to trigger this, please give it a try. This is an availability issue as untrusted user space could bring down the whole system. >=20 > Jan, I'm not familiar the migration, do you have interest to add the mi= gration part fixing? >=20 I'm not up to date with what is going on in the context of CPU feature configuration, CC'ing folks who reworked this recently. In any case, the general pattern is: make this configurable (=3D> CPU feature flag) and then possibly also adjust it for compat QEMU machine types. Jan --------------enig91391D624A05502AC21F801A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCXW0IACgkQitSsb3rl5xSI/wCg0svQiJ2Y/cbQzltVFKkrAU44 0F4AoNFvfq+wOttSA1CUOfejbUcvFFM5 =7eIE -----END PGP SIGNATURE----- --------------enig91391D624A05502AC21F801A--