From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsDUv-0004kH-QG for qemu-devel@nongnu.org; Mon, 07 Jan 2013 09:16:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsDUq-0000b4-L9 for qemu-devel@nongnu.org; Mon, 07 Jan 2013 09:16:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsDUq-0000ar-DH for qemu-devel@nongnu.org; Mon, 07 Jan 2013 09:16:12 -0500 Date: Mon, 7 Jan 2013 11:40:08 -0200 From: Luiz Capitulino Message-ID: <20130107114008.7419e2fd@doriath.home> In-Reply-To: <50EAC956.40409@suse.de> References: <50D55DB2.6080601@cn.fujitsu.com> <87lic5b3j0.fsf@blackfin.pond.sub.org> <50EAC956.40409@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] fix bits 39:32 of the final physical address when using 4M page List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?B?RuRyYmVy?= Cc: Markus Armbruster , qemu-devel On Mon, 07 Jan 2013 14:10:46 +0100 Andreas F=E4rber wrote: > Am 07.01.2013 13:06, schrieb Markus Armbruster: > > Wen Congyang writes: > >=20 > >> ((pde & 0x1fe000) << 19) is the bits 39:32 of the final physical addre= ss, and > >> we shouldn't use unit32_t to calculate it. Convert the type to hwaddr = to fix > >> this problem. > >=20 > > Spotted by Coverity. > >=20 > >> Signed-off-by: Wen Congyang > >> > >> --- > >> target-i386/arch_memory_mapping.c | 11 ++++++++--- > >> 1 file changed, 8 insertions(+), 3 deletions(-) > >> > >> diff --git a/target-i386/arch_memory_mapping.c b/target-i386/arch_memo= ry_mapping.c > >> index c6c7874..844893f 100644 > >> --- a/target-i386/arch_memory_mapping.c > >> +++ b/target-i386/arch_memory_mapping.c > >> @@ -115,7 +115,7 @@ static void walk_pde2(MemoryMappingList *list, > >> hwaddr pde_start_addr, int32_t a20_mask, > >> bool pse) > >> { > >> - hwaddr pde_addr, pte_start_addr, start_paddr; > >> + hwaddr pde_addr, pte_start_addr, start_paddr, high_paddr; > >> uint32_t pde; > >> target_ulong line_addr, start_vaddr; > >> int i; > >> @@ -130,8 +130,13 @@ static void walk_pde2(MemoryMappingList *list, > >> =20 > >> line_addr =3D (((unsigned int)i & 0x3ff) << 22); > >> if ((pde & PG_PSE_MASK) && pse) { > >> - /* 4 MB page */ > >> - start_paddr =3D (pde & ~0x3fffff) | ((pde & 0x1fe000) << = 19); > >> + /* > >> + * 4 MB page: > >> + * bits 39:32 are bits 20:13 of the PDE > >> + * bit3 31:22 are bits 31:22 of the PDE > >> + */ > >> + high_paddr =3D ((hwaddr)(pde & 0x1fe000) << 19); > >> + start_paddr =3D (pde & ~0x3fffff) | high_paddr; > >> if (cpu_physical_memory_is_io(start_paddr)) { > >> /* I/O region */ > >> continue; > >=20 > > Extra points for extending the comment. >=20 > ...and a "target-i386: " prefix in the subject would be appreciated, > since it does not seem to fix a general issue. I can do that myself when I apply the patch (which will take a little bit, as I'm just back from vacation). >=20 > Andreas >=20 > >=20 > > Reviewed-by: Markus Armbruster > >=20 >=20 >=20