From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:41876)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <sw@weilnetz.de>) id 1TJpx8-0005ap-Ab
	for qemu-devel@nongnu.org; Thu, 04 Oct 2012 14:15:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <sw@weilnetz.de>) id 1TJpx5-0001TG-Az
	for qemu-devel@nongnu.org; Thu, 04 Oct 2012 14:15:18 -0400
Received: from v220110690675601.yourvserver.net ([78.47.199.172]:58346)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <sw@weilnetz.de>) id 1TJpx5-0001S7-4m
	for qemu-devel@nongnu.org; Thu, 04 Oct 2012 14:15:15 -0400
Message-ID: <506DD230.70509@weilnetz.de>
Date: Thu, 04 Oct 2012 20:15:12 +0200
From: Stefan Weil <sw@weilnetz.de>
MIME-Version: 1.0
References: <1349346964-4151-1-git-send-email-avi@redhat.com>
In-Reply-To: <1349346964-4151-1-git-send-email-avi@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2] Make target_phys_addr_t 64 bits
	unconditionally
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Jia Liu <proljc@gmail.com>, qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, Michael Walle <michael@walle.cc>, Paul Brook <paul@codesourcery.com>, Anthony Liguori <anthony@codemonkey.ws>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Aurelien Jarno <aurelien@aurel32.net>

Am 04.10.2012 12:36, schrieb Avi Kivity:
> The hassle and compile time overhead of maintaining both 32-bit and 64-bit
> capable source isn't worth the tiny performance advantage which is seen on
> a minority of configurations.  Switch to compiling libhw only once, with
> target_phys_addr_t unconditionally typedefed to uint64_t.
>
> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
>
> v2: no changes, but copied the maintainers of architectures that will
>      see their target_phys_addr_t changed as a result.  Please view and/or
>      test.
>
>   .gitignore              |  1 +
>   Makefile                |  2 +-
>   Makefile.hw             |  1 -
>   Makefile.target         |  3 ---
>   configure               | 34 ++++------------------------------
>   cpu-common.h            |  2 +-
>   dma.h                   |  2 +-
>   hw/hw.h                 |  2 +-
>   hw/intel-hda.c          |  8 +-------
>   hw/rtl8139.c            |  6 +-----
>   monitor.c               |  4 ----
>   target-ppc/mmu_helper.c |  4 +---
>   targphys.h              | 19 +------------------
>   13 files changed, 13 insertions(+), 75 deletions(-)
>


Hi,

I noticed that you replaced target_phys_addr_t by uint64_t in two lines.
Are there plans to replace target_phys_addr_t everywhere?
Should new code use uint64_t, or should it continue to use 
target_phys_addr_t?

Using target_phys_addr_t might make support for 128 bit in some years easier
because it allows identifying critical code,
although I think it will be difficult to avoid wrong use of either 
target_phys_addr_t
or uint64_t as long as both are the same size.

Regards

Stefan W.


> -#if TARGET_PHYS_ADDR_BITS > 32
> -    return low | ((target_phys_addr_t)high << 32);
> -#else
> -    return low;
> -#endif
> +    return low | ((uint64_t)high << 32);
>

> -        *raddrp |= (target_phys_addr_t)(tlb->RPN & 0xF) << 32;
> +        *raddrp |= (uint64_t)(tlb->RPN & 0xF) << 32;