All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: KVM <kvm@vger.kernel.org>,
	Varun Sethi <Varun.Sethi@freescale.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: VFIO iommu page size masking
Date: Fri, 13 Feb 2015 10:31:32 -0600	[thread overview]
Message-ID: <1423845092.5253.18.camel@redhat.com> (raw)
In-Reply-To: <54DD6477.9050008@suse.de>

On Fri, 2015-02-13 at 03:41 +0100, Alexander Graf wrote:
> Hi Alex,
> 
> While trying to get VFIO-PCI working on AArch64 (with 64k page size), I
> stumbled over the following piece of code:
> 
> > static unsigned long vfio_pgsize_bitmap(struct vfio_iommu *iommu)
> > {
> >         struct vfio_domain *domain;
> >         unsigned long bitmap = PAGE_MASK;
> > 
> >         mutex_lock(&iommu->lock);
> >         list_for_each_entry(domain, &iommu->domain_list, next)
> >                 bitmap &= domain->domain->ops->pgsize_bitmap;
> >         mutex_unlock(&iommu->lock);
> > 
> >         return bitmap;
> > }
> 
> The SMMU page mask is
> 
> [    3.054302] arm-smmu e0a00000.smmu: 	Supported page sizes: 0x40201000
> 
> but after this function, we end up supporting one 2MB pages and above.
> The reason for that is simple: You restrict the bitmap to PAGE_MASK and
> above.
> 
> Now the big question is why you're doing that. I don't see why it would
> be a problem if the IOMMU maps a page in smaller chunks.
> 
> So I tried to patch the code above with s/PAGE_MASK/1UL/ and everything
> seems to run fine. But maybe we're not lacking some sanity checks?

Hey Alex,

Yeah, we may need to double check if we prevent sub-PAGE_SIZE mappings
elsewhere in the DMA mapping path, but that's probably the right thing
to do.  On x86 we have AMD-Vi, which actually supports just about any
power-of-two mapping and therefore exposes effectively PAGE_MASK and
VT-d, which only natively supports a few page sizes, but breaks down
mappings itself and therefore muddies the interface by exposing
PAGE_MASK also.  So the IOMMU API ends up not really being a way to
expose native IOMMU page sizes anyway.

BTW, I'm on holiday until late next week, so I apologize to all the vfio
threads that won't be getting any attention until then.  Thanks,

Alex


      reply	other threads:[~2015-02-13 16:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13  2:41 VFIO iommu page size masking Alexander Graf
2015-02-13 16:31 ` Alex Williamson [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=1423845092.5253.18.camel@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=Varun.Sethi@freescale.com \
    --cc=agraf@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /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.