On Wed, May 20, 2015 at 03:12:24PM +0100, Julien Grall wrote:
> On 20/05/15 14:40, Edgar E. Iglesias wrote:
> > Thanks for the pointers,
> >
> > I agree that fundamental differences like these beteween v7 and v8 wouldn't
> > be good.
>
> I didn't find any fundamental differences for device memory
On 20/05/15 14:40, Edgar E. Iglesias wrote:
> Thanks for the pointers,
>
> I agree that fundamental differences like these beteween v7 and v8 wouldn't
> be good.
I didn't find any fundamental differences for device memory behavior in
the spec.
> Possible unpredictable behaviour is worrysome...
>
On Tue, May 19, 2015 at 10:23:05AM +0100, Julien Grall wrote:
>
>
> On 19/05/2015 10:09, Ian Campbell wrote:
> >On Tue, 2015-05-19 at 15:16 +1000, Edgar E. Iglesias wrote:
> >>Hi,
>
> Hi,
>
> >>The rules for combining the memory attributes from S1 and S2 translations
> >>suggest that mapping th
On 19/05/2015 10:09, Ian Campbell wrote:
On Tue, 2015-05-19 at 15:16 +1000, Edgar E. Iglesias wrote:
Hi,
Hi,
The rules for combining the memory attributes from S1 and S2 translations
suggest that mapping things at S2 with Normal memory Inner/Outer WB cacheable
would give the guest/S1 flexi
On Tue, 2015-05-19 at 15:16 +1000, Edgar E. Iglesias wrote:
> Hi,
>
> I'd like to support the assignment of on chip RAMs to guests, starting with
> dom0.
>
> The mmio-sram compatible device kinda works already but the 2nd stage MMU
> mapping is done with DEVICE memory attributes. This doesn't wo
Hi,
I'd like to support the assignment of on chip RAMs to guests, starting with
dom0.
The mmio-sram compatible device kinda works already but the 2nd stage MMU
mapping is done with DEVICE memory attributes. This doesn't work well for
SRAMs for several reasons (e.g performance, alignment checks e
