[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