Re: [Qemu-devel] [PATCH 0/2] [RFC] 64-bit io paths

[Paul Brook]

[Hit send too early on previous mail...]
> 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 might 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.

I suggest adding a MemoryCallbackInfo* argument to qemu_ram_alloc_r.
If NULL this allocates a regular RAM block.  if non-null it allocates a hybrid 
ROM/IO block using the specified callbacks for IO accesses.  Then introduce a 
function that allows a device to switch a mapping between ROM and IO modes.  
Likewise to make a mapping of a RAM region readonly.



Paul