All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Mitchel Humpherys <mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 2/2] iommu/arm-smmu: add support for iova_to_phys through ATS1PR
Date: Fri, 26 Sep 2014 11:24:30 +0100	[thread overview]
Message-ID: <20140926102430.GF22293@arm.com> (raw)
In-Reply-To: <vnkw38bgkbal.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>

On Wed, Sep 24, 2014 at 09:34:26PM +0100, Mitchel Humpherys wrote:
> On Wed, Sep 24 2014 at 09:37:12 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Wed, Sep 24, 2014 at 02:12:00AM +0100, Mitchel Humpherys wrote:
> >> On Mon, Sep 22 2014 at 08:26:14 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> >> > On Thu, Sep 11, 2014 at 07:30:44PM +0100, Mitchel Humpherys wrote:
> >> >> +		return arm_smmu_iova_to_phys_soft(domain, iova);
> >> >> +	}
> >> >> +
> >> >> +	phys = readl_relaxed(cb_base + ARM_SMMU_CB_PAR_LO);
> >> >> +	phys |= ((u64) readl_relaxed(cb_base + ARM_SMMU_CB_PAR_HI)) << 32;
> >> >> +
> >> >> +	if (phys & CB_PAR_F) {
> >> >> +		dev_err(dev, "translation fault on %s!\n", dev_name(dev));
> >> >> +		dev_err(dev, "PAR = 0x%llx\n", phys);
> >> >> +	}
> >> >> +	phys = (phys & 0xFFFFFFF000ULL) | (iova & 0x00000FFF);
> >> >
> >> > How does this work for 64k pages?
> >> 
> >> So at the moment we're always assuming that we're using v7/v8 long
> >> descriptor format, right?  All I see in the spec (14.5.15 SMMU_CBn_PAR)
> >> is that bits[47:12]=>PA[47:12]...  Or am I missing something completely?
> >
> > I think you've got 64k pages confused with the short-descriptor format.
> >
> > When we use 64k pages with long descriptors, you're masked off bits 15-12 of
> > the iova above, so you'll have a hole in the physical address afaict.
> 
> Even with long descriptors the spec says bits 15-12 should come from
> CB_PAR...  It makes no mention of reinterpreting those bits depending on
> the programmed page granule.  The only thing I can conclude from the
> spec is that hardware should be smart enough to do the right thing with
> bits 15-12 when the page granule is 64k.  Although even if hardware is
> smart enough I guess CB_PAR[15:12] should be the same as iova[15:12] for
> the 64k case?

Yeah, fair enough, the code you have should work correctly then.
Unfortunately, I don't have any suitable hardware on which to test it.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] iommu/arm-smmu: add support for iova_to_phys through ATS1PR
Date: Fri, 26 Sep 2014 11:24:30 +0100	[thread overview]
Message-ID: <20140926102430.GF22293@arm.com> (raw)
In-Reply-To: <vnkw38bgkbal.fsf@mitchelh-linux.qualcomm.com>

On Wed, Sep 24, 2014 at 09:34:26PM +0100, Mitchel Humpherys wrote:
> On Wed, Sep 24 2014 at 09:37:12 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Sep 24, 2014 at 02:12:00AM +0100, Mitchel Humpherys wrote:
> >> On Mon, Sep 22 2014 at 08:26:14 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Thu, Sep 11, 2014 at 07:30:44PM +0100, Mitchel Humpherys wrote:
> >> >> +		return arm_smmu_iova_to_phys_soft(domain, iova);
> >> >> +	}
> >> >> +
> >> >> +	phys = readl_relaxed(cb_base + ARM_SMMU_CB_PAR_LO);
> >> >> +	phys |= ((u64) readl_relaxed(cb_base + ARM_SMMU_CB_PAR_HI)) << 32;
> >> >> +
> >> >> +	if (phys & CB_PAR_F) {
> >> >> +		dev_err(dev, "translation fault on %s!\n", dev_name(dev));
> >> >> +		dev_err(dev, "PAR = 0x%llx\n", phys);
> >> >> +	}
> >> >> +	phys = (phys & 0xFFFFFFF000ULL) | (iova & 0x00000FFF);
> >> >
> >> > How does this work for 64k pages?
> >> 
> >> So at the moment we're always assuming that we're using v7/v8 long
> >> descriptor format, right?  All I see in the spec (14.5.15 SMMU_CBn_PAR)
> >> is that bits[47:12]=>PA[47:12]...  Or am I missing something completely?
> >
> > I think you've got 64k pages confused with the short-descriptor format.
> >
> > When we use 64k pages with long descriptors, you're masked off bits 15-12 of
> > the iova above, so you'll have a hole in the physical address afaict.
> 
> Even with long descriptors the spec says bits 15-12 should come from
> CB_PAR...  It makes no mention of reinterpreting those bits depending on
> the programmed page granule.  The only thing I can conclude from the
> spec is that hardware should be smart enough to do the right thing with
> bits 15-12 when the page granule is 64k.  Although even if hardware is
> smart enough I guess CB_PAR[15:12] should be the same as iova[15:12] for
> the 64k case?

Yeah, fair enough, the code you have should work correctly then.
Unfortunately, I don't have any suitable hardware on which to test it.

Will

  parent reply	other threads:[~2014-09-26 10:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11 18:30 [PATCH 0/2] iommu/arm-smmu: hard iova_to_phys Mitchel Humpherys
2014-09-11 18:30 ` Mitchel Humpherys
     [not found] ` <1410460244-18943-1-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-11 18:30   ` [PATCH 1/2] iopoll: Introduce memory-mapped IO polling macros Mitchel Humpherys
2014-09-11 18:30     ` Mitchel Humpherys
     [not found]     ` <1410460244-18943-2-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-22 15:23       ` Will Deacon
2014-09-22 15:23         ` Will Deacon
2014-09-11 18:30   ` [PATCH 2/2] iommu/arm-smmu: add support for iova_to_phys through ATS1PR Mitchel Humpherys
2014-09-11 18:30     ` Mitchel Humpherys
     [not found]     ` <1410460244-18943-3-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-22 15:26       ` Will Deacon
2014-09-22 15:26         ` Will Deacon
     [not found]         ` <20140922152614.GP25809-5wv7dgnIgG8@public.gmane.org>
2014-09-24  1:12           ` Mitchel Humpherys
2014-09-24  1:12             ` Mitchel Humpherys
     [not found]             ` <vnkwiokdx1nj.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2014-09-24 16:37               ` Will Deacon
2014-09-24 16:37                 ` Will Deacon
     [not found]                 ` <20140924163712.GG16244-5wv7dgnIgG8@public.gmane.org>
2014-09-24 20:34                   ` Mitchel Humpherys
2014-09-24 20:34                     ` Mitchel Humpherys
     [not found]                     ` <vnkw38bgkbal.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2014-09-26 10:24                       ` Will Deacon [this message]
2014-09-26 10:24                         ` Will Deacon
     [not found]                         ` <20140926102430.GF22293-5wv7dgnIgG8@public.gmane.org>
2014-09-26 17:20                           ` Mitchel Humpherys
2014-09-26 17:20                             ` Mitchel Humpherys
2014-09-11 18:53   ` [PATCH 0/2] iommu/arm-smmu: hard iova_to_phys Mitchel Humpherys
2014-09-11 18:53     ` Mitchel Humpherys

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=20140926102430.GF22293@arm.com \
    --to=will.deacon-5wv7dgnigg8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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.