All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Will Deacon <will@kernel.org>
Cc: will.deacon@arm.com, robin.murphy@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Why doesn't arm-smmu (v2) driver take VA_BITS into consideration?
Date: Fri, 28 Jun 2019 01:10:07 -0700	[thread overview]
Message-ID: <20190628081006.GA6628@Asurada> (raw)
In-Reply-To: <20190627102640.2pzgiro3gq3ont5s@willie-the-truck>

Hi Will,

On Thu, Jun 27, 2019 at 11:26:40AM +0100, Will Deacon wrote:
> On Wed, Jun 26, 2019 at 05:19:33PM -0700, Nicolin Chen wrote:
> > I am using an Soc that contains arm-smmu v2 engines. I found that
> > the arm-smmu driver reads GR_ID2 register and defines ias and oas
> > of each domain based on the corresponding fields of that GR_ID2.
> > 
> > Using my platform for example, it gets 48-bit for all ias and oas,
> > being translated from those fields so I got these 2 stages:
> >         Stage-1: 48-bit VA -> 48-bit IPA
> >         Stage-2: 48-bit IPA -> 48-bit PA
> > 
> > Then the code does below to configure aperture_end to 48-bit:
> >  914         domain->geometry.aperture_end = (1UL << ias) - 1;
> > 
> > However, my system configures VA_BITS to 39. So aperture_end==48
> > is a mismatch comparing to VA_BITS_39. Although the aperture_end
> > is supposed to cap IOVA allocation, this 48-bit cap won't really
> > do the job at all.
> 
> What actually goes wrong, though? IOVAs should only be handed over to
> devices, so VA_BITS doesn't strictly matter. It's the DMA masks that are
> important.

Ah..that's true. I think I misunderstood one of my situations here.

> > I saw that arm-smmu-v3 driver takes VA_BITS into consideration:
> >  1765         switch (smmu_domain->stage) {
> >  1766         case ARM_SMMU_DOMAIN_S1:
> >  1767                 ias = (smmu->features & ARM_SMMU_FEAT_VAX) ?
> >  1768                 ias = min_t(unsigned long, ias, VA_BITS);
> > 
> > So I am wondering if it is intentionally designed so by ignoring
> > VA_BITS? Would you please help me understand this a bit?
> 
> I think it's simply that SMMUv3 doesn't provide an ID field to tell you
> what to use, so we chose to go with VA_BITS since it's what we're using
> on the CPU.

I see. Thanks for explaining!

Nicolin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2019-06-28  8:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27  0:19 Why doesn't arm-smmu (v2) driver take VA_BITS into consideration? Nicolin Chen
2019-06-27 10:26 ` Will Deacon
2019-06-28  8:10   ` Nicolin Chen [this message]

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=20190628081006.GA6628@Asurada \
    --to=nicoleotsuka@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=will.deacon@arm.com \
    --cc=will@kernel.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.