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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.

>> Yes. How would that work in practice? I guess some of the guests memory space
>> would not be DMA:able? or would we allow some kind of dynamic mapping
>> driven from the guest?
> 
> For domU with passthrough enabled there would be a limitation on the
> maximum usable IPA I suppose.

Right.

> 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.

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.

Regards,

-- 
Julien Grall

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