Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Olivier Galibert
On Tue, Jun 28, 2011 at 03:09:38PM +0300, Avi Kivity wrote: > On 06/28/2011 03:07 PM, Jan Kiszka wrote: > > > > > > The point is that different buses have different widths. > > > target_phys_addr_t matches just one bus in the system. It needs to be > > > the maximum size of all buses present to

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Avi Kivity
On 06/28/2011 04:25 PM, Peter Maydell wrote: On 28 June 2011 13:09, Avi Kivity wrote: > Okay, let's make t_p_a_t max(bus size in system). If you want a type for that, can't you give it a sensible (ie different) name? target_phys_addr_t is pretty clearly "the type of a physical address for thi

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Peter Maydell
On 28 June 2011 13:09, Avi Kivity wrote: > Okay, let's make t_p_a_t max(bus size in system). If you want a type for that, can't you give it a sensible (ie different) name? target_phys_addr_t is pretty clearly "the type of a physical address for this target" and having it actually be something els

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Avi Kivity
On 06/28/2011 03:46 PM, Jan Kiszka wrote: > Do we want to support a 32-bit variant of pci? It certainly existed at > some point. As long as making everything 64 bit in the implementation of the device models is not guest visible, I don't think that should be a problem. How would it become

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Jan Kiszka
On 2011-06-28 14:09, Avi Kivity wrote: > On 06/28/2011 03:07 PM, Jan Kiszka wrote: >>> >>> The point is that different buses have different widths. >>> target_phys_addr_t matches just one bus in the system. It needs to be >>> the maximum size of all buses present to be useful. >> >> Then we nee

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Avi Kivity
On 06/28/2011 03:07 PM, Jan Kiszka wrote: > > The point is that different buses have different widths. > target_phys_addr_t matches just one bus in the system. It needs to be > the maximum size of all buses present to be useful. Then we need a type for that. Or we need to demand that target_

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Jan Kiszka
On 2011-06-28 13:53, Avi Kivity wrote: > On 06/28/2011 01:28 PM, Jan Kiszka wrote: >> On 2011-06-28 12:03, Michael S. Tsirkin wrote: +struct MemoryRegion { +/* All fields are private - violators will be prosecuted */ +const MemoryRegionOps *ops; +MemoryRegion *pa

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Avi Kivity
On 06/28/2011 01:28 PM, Jan Kiszka wrote: On 2011-06-28 12:03, Michael S. Tsirkin wrote: >> +struct MemoryRegion { >> +/* All fields are private - violators will be prosecuted */ >> +const MemoryRegionOps *ops; >> +MemoryRegion *parent; >> +uint64_t size; >> +target_phys

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Avi Kivity
On 06/28/2011 01:03 PM, Michael S. Tsirkin wrote: On Mon, Jun 27, 2011 at 04:21:48PM +0300, Avi Kivity wrote: ... > +static bool memory_region_access_valid(MemoryRegion *mr, > + target_phys_addr_t addr, > + unsigned

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Jan Kiszka
On 2011-06-28 12:03, Michael S. Tsirkin wrote: >> +struct MemoryRegion { >> +/* All fields are private - violators will be prosecuted */ >> +const MemoryRegionOps *ops; >> +MemoryRegion *parent; >> +uint64_t size; >> +target_phys_addr_t addr; >> +target_phys_addr_t offset; >

Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-28 Thread Michael S. Tsirkin
On Mon, Jun 27, 2011 at 04:21:48PM +0300, Avi Kivity wrote: ... > +static bool memory_region_access_valid(MemoryRegion *mr, > + target_phys_addr_t addr, > + unsigned size) > +{ > +if (!mr->ops->valid.unaligned && (add

[Qemu-devel] [RFC v2 01/20] Hierarchical memory region API

2011-06-27 Thread Avi Kivity
The memory API separates the attributes of a memory region (its size, how reads or writes are handled, dirty logging, and coalescing) from where it is mapped and whether it is enabled. This allows a device to configure a memory region once, then hand it off to its parent bus to map it according to