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
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
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;
>
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
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
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
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_
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
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
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
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
11 matches
Mail list logo
