[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


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


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.