On 05/22/2011 06:44 PM, Anthony Liguori wrote:
At any rate, I'm fairly sure it doesn't belong in the MemoryRegion
structure.
Since it isn't a global property, where does it belong?
The chipset should have an intercept in the dispatch path that
enforces this (this assumes hierarchical di
On 05/22/2011 06:46 PM, Anthony Liguori wrote:
MemoryRegion *is* the dispatch path. Only done declaratively so we can
flatten it whenever it changes.
We don't want dispatch to be 100% declarative. That's what will cause
the API to get horrendously ugly.
An example is PCI-bus level endianne
On 05/22/2011 01:39 AM, Avi Kivity wrote:
On 05/20/2011 05:46 PM, Anthony Liguori wrote:
On 05/20/2011 09:40 AM, Richard Henderson wrote:
On 05/20/2011 07:31 AM, Anthony Liguori wrote:
But is this a characteristic of devices or is this a characteristic
of the chipset/CPU?
Chipset.
So if th
On 05/22/2011 01:38 AM, Avi Kivity wrote:
On 05/20/2011 05:31 PM, Anthony Liguori wrote:
Several alpha system chips MCE when accessed with incorrect sizes.
E.g. only 64-bit accesses are allowed.
But is this a characteristic of devices or is this a characteristic of
the chipset/CPU?
The chip
On 05/22/2011 06:32 PM, Blue Swirl wrote:
>
> Can you suggest an alternative naming for the API?
How about
memory_region_container_init()
memory_region_add()
I'm neutral. If someone seconds this, I'll make it so.
--
I have a truly marvellous patch that fixes the bug which this
signature is
On Sun, May 22, 2011 at 3:18 PM, Avi Kivity wrote:
> On 05/22/2011 03:06 PM, Blue Swirl wrote:
>>
>> On Sun, May 22, 2011 at 2:36 PM, Avi Kivity wrote:
>> > On 05/22/2011 12:32 PM, Blue Swirl wrote:
>> >>
>> >> >> > +void memory_region_add_coalescing(MemoryRegion *mr,
>> >> >> >
On 05/22/2011 03:06 PM, Blue Swirl wrote:
On Sun, May 22, 2011 at 2:36 PM, Avi Kivity wrote:
> On 05/22/2011 12:32 PM, Blue Swirl wrote:
>>
>> >>> +void memory_region_add_coalescing(MemoryRegion *mr,
>> >>> + target_phys_addr_t offset,
>> >>
On Sun, May 22, 2011 at 2:36 PM, Avi Kivity wrote:
> On 05/22/2011 12:32 PM, Blue Swirl wrote:
>>
>> >> > +void memory_region_add_coalescing(MemoryRegion *mr,
>> >> > + target_phys_addr_t offset,
>> >> > + target_phys_ad
On 05/22/2011 12:32 PM, Blue Swirl wrote:
>> >+void memory_region_add_coalescing(MemoryRegion *mr,
>> >+ target_phys_addr_t offset,
>> >+ target_phys_addr_t size);
>> >+/* Disable MMIO coalescing for the region.
On Sun, May 22, 2011 at 9:45 AM, Avi Kivity wrote:
> On 05/20/2011 08:59 PM, Blue Swirl wrote:
>>
>> On Thu, May 19, 2011 at 5:12 PM, Avi Kivity wrote:
>> > The memory API separates the attributes of a memory region (its size,
>> > how
>> > reads or writes are handled, dirty logging, and coales
On 05/20/2011 08:59 PM, Blue Swirl wrote:
On Thu, May 19, 2011 at 5:12 PM, Avi Kivity wrote:
> 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 all
On 05/20/2011 05:06 PM, Richard Henderson wrote:
Is this structure honestly any better than 4 function pointers?
I can't see that it is, myself.
That was requested by Anthony. And in fact we have two bits of
information per access size, one is whether the access is allowed or
not, the other
On 05/20/2011 08:59 PM, Blue Swirl wrote:
On Thu, May 19, 2011 at 5:12 PM, Avi Kivity wrote:
> 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 all
On 05/20/2011 09:16 PM, Blue Swirl wrote:
On Fri, May 20, 2011 at 5:46 PM, Anthony Liguori wrote:
> On 05/20/2011 09:40 AM, Richard Henderson wrote:
>>
>> On 05/20/2011 07:31 AM, Anthony Liguori wrote:
>>>
>>> But is this a characteristic of devices or is this a characteristic of
>>> the chi
On 05/20/2011 05:46 PM, Anthony Liguori wrote:
On 05/20/2011 09:40 AM, Richard Henderson wrote:
On 05/20/2011 07:31 AM, Anthony Liguori wrote:
But is this a characteristic of devices or is this a characteristic
of the chipset/CPU?
Chipset.
So if the chipset only allows accesses that are 64-
On 05/20/2011 05:31 PM, Anthony Liguori wrote:
Several alpha system chips MCE when accessed with incorrect sizes.
E.g. only 64-bit accesses are allowed.
But is this a characteristic of devices or is this a characteristic of
the chipset/CPU?
The chipset is modelled by a MemoryRegion too.
On Fri, May 20, 2011 at 5:46 PM, Anthony Liguori wrote:
> On 05/20/2011 09:40 AM, Richard Henderson wrote:
>>
>> On 05/20/2011 07:31 AM, Anthony Liguori wrote:
>>>
>>> But is this a characteristic of devices or is this a characteristic of
>>> the chipset/CPU?
>>
>> Chipset.
>
> So if the chipset o
On Thu, May 19, 2011 at 5:12 PM, Avi Kivity wrote:
> 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 onc
On 05/20/2011 09:40 AM, Richard Henderson wrote:
On 05/20/2011 07:31 AM, Anthony Liguori wrote:
But is this a characteristic of devices or is this a characteristic of the
chipset/CPU?
Chipset.
So if the chipset only allows accesses that are 64-bit, then you'll want
to have hierarchical dis
On 05/20/2011 07:31 AM, Anthony Liguori wrote:
> But is this a characteristic of devices or is this a characteristic of the
> chipset/CPU?
Chipset.
r~
On 05/20/2011 09:06 AM, Richard Henderson wrote:
On 05/20/2011 02:23 AM, Avi Kivity wrote:
On 05/19/2011 11:43 PM, Anthony Liguori wrote:
On 05/19/2011 09:12 AM, Avi Kivity wrote:
The memory API separates the attributes of a memory region (its size, how
reads or writes are handled, dirty loggi
On 05/20/2011 02:23 AM, Avi Kivity wrote:
> On 05/19/2011 11:43 PM, Anthony Liguori wrote:
>> On 05/19/2011 09:12 AM, Avi Kivity wrote:
>>> 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
On 05/20/2011 12:11 AM, Stefan Hajnoczi wrote:
On Thu, May 19, 2011 at 3:12 PM, Avi Kivity wrote:
> +struct MemoryRegion {
> +/* All fields are private - violators will be prosecuted */
> +const MemoryRegionOps *ops;
> +MemoryRegion *parent;
In the case where a region is aliased
On 05/20/2011 12:04 AM, Stefan Weil wrote:
Am 19.05.2011 16:12, schrieb 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 c
On 05/19/2011 11:43 PM, Anthony Liguori wrote:
On 05/19/2011 09:12 AM, Avi Kivity wrote:
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 devic
On 05/19/2011 10:27 PM, Jan Kiszka wrote:
On 2011-05-19 16:12, Avi Kivity wrote:
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
Please mark this as a legacy helper, ideally to be removed after the
On 05/19/2011 10:07 PM, Alex Williamson wrote:
On Thu, 2011-05-19 at 10:12 -0400, Avi Kivity wrote:
> 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. Th
On Thu, May 19, 2011 at 3:12 PM, Avi Kivity wrote:
> +struct MemoryRegion {
> + /* All fields are private - violators will be prosecuted */
> + const MemoryRegionOps *ops;
> + MemoryRegion *parent;
In the case where a region is aliased (mapped twice into the address
space at different ad
Am 19.05.2011 16:12, schrieb 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 of
On 05/19/2011 09:12 AM, Avi Kivity wrote:
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
On 2011-05-19 16:12, Avi Kivity wrote:
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
Please mark this as a legacy helper, ideally to be removed after the
complete conversion to this API. During that
On Thu, 2011-05-19 at 10:12 -0400, Avi Kivity wrote:
> 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 on
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
33 matches
Mail list logo
