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

Re: [Xen-devel] [RFC 0/2] Cap SMMU s2 input-size based on p2m tables



On 27/04/15 10:24, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>
> 
> Hi,

Hi Edgar,

> This is a first try at fixing the issue I'm seeing on ZynqMP with
> missmatched setup of the SMMU and the shared page-tables with p2m.
> 
> I've only handled the case of having an SMMU that supports larger
> s2 input-sizes than what p2m wants to use.
> 
> To support the case were the system has SMMUs that can only do smaller
> input-sizes than the CPU, I think we will need to walk the device-tree
> when creating domains and somehow cap the p2m IPA size to the largest
> supported S2 size across the SMMUs used by that particular domain.
> The max IPA size may need to be domain specific.
> I did not implement this but I did make the max size domain specific.
> Julien, you mentioned you might have access to such a system?

Right, I got an AMD Seattle where the IPA is limited by the SMMU. From
Xen output:
   - SMMU: 40-bit IPA -> 40-bit PA
   - P2M: 44-bit IPA with 44-bit PA

Suravee, can you confirm that this is actually the case?

> 
> Does this look reasonable or should we be fixing this some other way?
> I could make the patch simpler I guess by having a global (not
> domain specific) max value set once aswell.

For your use case a global seems better (you may need to move the
iommu_setup call after setup_virt_paging).

Although, if the limitation of the SMMU on Seattle is confirmed, that
would restrict domain memory to 1TB maximum (rather than 16TB) on this
platform.

Regards,

-- 
Julien Grall

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


 


Rackspace

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