Re: [Xen-devel] [PATCH v4 0/3] Set SMMU s2 input-size based on p2m tables

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-05-06 at 12:06 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 06/05/15 10:39, Ian Campbell wrote:
> > On Wed, 2015-05-06 at 19:17 +1000, Edgar E. Iglesias wrote:
> >>> Right, it seems like we may eventually need to introduce the possibility
> >>> of not sharing the p2m depending on the circumstances as is done on x86.
> 
> I'd like to avoid non-share P2M as much as possible. It would also not
> help in the situation where bits(SMMU) < bits(MMU-s2), at least in case
> of DOM0.
> 
> For DOM0 with direct memory mapping (currently the default), every grant
> table page are also mapped 1:1 in order to use them in DMA requests.
> This is because dev_bus_addr return by the hypercall is the MFN (not the
> IPA).
> 
> The direct memory mapping could only be dropped if all the devices using
> DMA are protected by an SMMU.

Correct, I was talking mainly about the case where we would otherwise be
able to drop the mapping, i.e. everything protected (IOW "RAM completely
covered" is a special case of "protected device").

> > For dom0 it's a bit trickier, but I think the answer is basically that
> > on systems with insufficiently large SMMU support and peripherals or RAM
> > above the SMMU's limit we wouldn't be able to take advantage of the SMMU
> > protections and would be stuck with e.g. 1:1 mode. If it was only RAM
> > and not peripherals up high then perhaps we could trade off use of SMMU
> > vs dom0 RAM size.
> 
> See a possible problem above. I think we would have to boot DOM0 without
> SMMU protection.

Right, I was thinking mainly of the non-1:1 SMMU is completely used
case.

> Although, given the complexity of the implementation, I would wait any
> feedback from AMD before considering to add SMMU support for platform
> where the SMMU handle less address bits than the MMU.

Agreed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel