From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=59492 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OI6Rl-0008UO-Dk
	for qemu-devel@nongnu.org; Fri, 28 May 2010 16:46:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OI6Rk-00013W-10
	for qemu-devel@nongnu.org; Fri, 28 May 2010 16:46:25 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:53160)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OI6Rj-000135-Pd
	for qemu-devel@nongnu.org; Fri, 28 May 2010 16:46:23 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths
Date: Fri, 28 May 2010 21:45:51 +0100
References: <cover.1271795219.git.rth@twiddle.net>
	<o2vf43fc5581004221301pec979bds874f2eb81096838d@mail.gmail.com>
	<4BD0BD6E.4010000@twiddle.net>
In-Reply-To: <4BD0BD6E.4010000@twiddle.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201005282145.51468.paul@codesourcery.com>
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.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>, agraf@suse.de, Richard Henderson <rth@twiddle.net>

> The basic device interface looks like
> ...
> +
> +/* Register a memory region at START_ADDR/SIZE.  The REGION structure will
> +   be initialized appropriately for DEV using CB as the operation set.  */
> +extern void cpu_register_memory_region(MemoryRegion *region,
> +                                       const MemoryCallbackInfo *cb,
> +                                       target_phys_addr_t start_addr,
> +                                       target_phys_addr_t size);
> +
> +/* Unregister a memory region.  */
> +extern void cpu_unregister_memory_region(MemoryRegion *);
> +
> +/* Allocate ram for use with cpu_register_memory_region.  */
> +extern const MemoryCallbackInfo *qemu_ram_alloc_r(ram_addr_t);
> +extern void qemu_ram_free_r(const MemoryCallbackInfo *);
> 
> The Basic Idea is that we have a MemoryRegion object that describes
> a contiguous mapping within the guest address space.  This object
> needs to handle RAM, ROM and devices.  The desire to handle memory
> and devices the same comes from the wish to have PCI device BARs
> show up as plain memory in the TLB as plain memory, and to be able
> to handle all PCI device regions identically within sysbus.

Looks reasonable to me.
I'm tempted to add a DeviceState* argument to cpu_register_memory_region.
This might be informative for debugging, and allow future disjoint bus 
support. OTOH it may be more trouble than it's worth.
 
> I will admit that I do not yet have a good replacement for IO_MEM_ROMD,

> or toggling the read-only bit on a RAM region.