All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@citrix.com>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, xen-devel@lists.xen.org
Cc: julien.grall@citrix.com, stefano.stabellini@citrix.com,
	tim@xen.org, ian.campbell@citrix.com,
	Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Subject: Re: [RFC 0/2] Cap SMMU s2 input-size based on p2m tables
Date: Tue, 28 Apr 2015 17:50:43 +0100	[thread overview]
Message-ID: <553FBA63.4010008@citrix.com> (raw)
In-Reply-To: <1430126688-21739-1-git-send-email-edgar.iglesias@gmail.com>

On 27/04/15 10:24, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> 
> 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

  parent reply	other threads:[~2015-04-28 16:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27  9:24 [RFC 0/2] Cap SMMU s2 input-size based on p2m tables Edgar E. Iglesias
2015-04-27  9:24 ` [RFC 1/2] xen/arm: Save and expose the p2m IPA address size Edgar E. Iglesias
2015-04-27  9:24 ` [RFC 2/2] xen/iommu: smmu: Use the p2m IPA size as S2 input-size Edgar E. Iglesias
2015-04-28 16:50 ` Julien Grall [this message]
2015-04-29  0:47   ` [RFC 0/2] Cap SMMU s2 input-size based on p2m tables Edgar E. Iglesias

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553FBA63.4010008@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.