From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IyArq-0007uw-Bl
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 13:45:38 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IyArl-0007rR-Rd
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 13:45:37 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IyArl-0007rN-KG
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 13:45:33 -0500
Received: from nf-out-0910.google.com ([64.233.182.186])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1IyArl-0007Rl-6G
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 13:45:33 -0500
Received: by nf-out-0910.google.com with SMTP id 30so2557490nfu
	for <qemu-devel@nongnu.org>; Fri, 30 Nov 2007 10:45:31 -0800 (PST)
Message-ID: <f43fc5580711301045k2d2a39cdkb6f6275e4af6d45c@mail.gmail.com>
Date: Fri, 30 Nov 2007 20:45:31 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] [RESEND] hw/sh7750.c: use TARGET_FMT_plx to
	printf target_phys_addr_t
In-Reply-To: <200711301742.49630.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20071111154922.GE25322@tapir>
	<200711301650.55751.paul@codesourcery.com>
	<f43fc5580711300916y4bc4c013y142904e16a5b4884@mail.gmail.com>
	<200711301742.49630.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>, qemu-devel <qemu-devel@nongnu.org>

On 11/30/07, Paul Brook <paul@codesourcery.com> wrote:
> > I think T2 may need to store host addresses as well. To be frank, I
> > don't understand that part  but there is a compiler warning on a 64
> > bit host.
>
> If you're thinking of the warnings in op_goto_tb0, these are actually due to
> tb->tb_next having the wrong type.

I meant this one (target-sparc/op_helper.c):
            if (tb) {
                /* the PC is inside the translated code. It means that we have
                   a virtual CPU fault */
                cpu_restore_state(tb, env, pc, (void *)T2);
            }

> > > In general all access to target memory should be via
> > > cpu_physcial_memory_{rw,read,write}
> > >
> > > For performance reasons we currently make an exception for framebuffer
> > > devices and allow them to access ram directly. ram_addr_t holds an offset
> > > from phys_ram_base.
> >
> > Even better would be to make separate device memory access functions
> > and hide this exception.
>
> cpu_physical_memory_* are the device memory access functions.

I meant a function to access memory from the device side, the effect
is of course identical on IOMMU-less system.