All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Eric Auger <eric.auger@linaro.org>
Cc: eric.auger@st.com, kvm@vger.kernel.org, patches@linaro.org,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size
Date: Wed, 28 Oct 2015 12:15:13 -0600	[thread overview]
Message-ID: <1446056113.8018.419.camel@redhat.com> (raw)
In-Reply-To: <56310D39.6090500@linaro.org>

On Wed, 2015-10-28 at 19:00 +0100, Eric Auger wrote:
> On 10/28/2015 06:55 PM, Will Deacon wrote:
> > On Wed, Oct 28, 2015 at 06:48:41PM +0100, Eric Auger wrote:
> >> On 10/28/2015 06:37 PM, Alex Williamson wrote:
> >>> Ok, so with hopefully correcting my understand of what this does, isn't
> >>> this effectively the same:
> >>>
> >>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> >>> index 57d8c37..7db4f5a 100644
> >>> --- a/drivers/vfio/vfio_iommu_type1.c
> >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> >>> @@ -403,13 +403,19 @@ static void vfio_remove_dma(struct vfio_iommu *iommu, stru
> >>>  static unsigned long vfio_pgsize_bitmap(struct vfio_iommu *iommu)
> >>>  {
> >>>         struct vfio_domain *domain;
> >>> -       unsigned long bitmap = PAGE_MASK;
> >>> +       unsigned long bitmap = ULONG_MAX;
> >>>  
> >>>         mutex_lock(&iommu->lock);
> >>>         list_for_each_entry(domain, &iommu->domain_list, next)
> >>>                 bitmap &= domain->domain->ops->pgsize_bitmap;
> >>>         mutex_unlock(&iommu->lock);
> >>>  
> >>> +       /* Some comment about how the IOMMU API splits requests */
> >>> +       if (bitmap & ~PAGE_MASK) {
> >>> +               bitmap &= PAGE_MASK;
> >>> +               bitmap |= PAGE_SIZE;
> >>> +       }
> >>> +
> >>>         return bitmap;
> >>>  }
> >> Yes, to me it is indeed the same
> >>>  
> >>> This would also expose to the user that we're accepting PAGE_SIZE, which
> >>> we weren't before, so it was not quite right to just let them do it
> >>> anyway.  I don't think we even need to get rid of the WARN_ONs, do we?
> >>> Thanks,
> >>
> >> The end-user might be afraid of those latter. Personally I would get rid
> >> of them but that's definitively up to you.
> > 
> > I think Alex's point is that the WARN_ON's won't trigger with this patch,
> > because he clears those lower bits in the bitmap.
> ah yes sure!

The WARN_ON triggers when the IOMMU mask is greater than PAGE_SIZE,
which means we can't operate on the IOMMU with PAGE_SIZE granularity,
which we do in a couple places.  So I think the WARN_ON is actually
valid for the code and won't trigger for you now that the IOMMU mask is
always at least ~PAGE_MASK if we can use the IOMMU at anything less than
PAGE_SIZE granularity.  Thanks,

Alex

WARNING: multiple messages have this Message-ID (diff)
From: alex.williamson@redhat.com (Alex Williamson)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size
Date: Wed, 28 Oct 2015 12:15:13 -0600	[thread overview]
Message-ID: <1446056113.8018.419.camel@redhat.com> (raw)
In-Reply-To: <56310D39.6090500@linaro.org>

On Wed, 2015-10-28 at 19:00 +0100, Eric Auger wrote:
> On 10/28/2015 06:55 PM, Will Deacon wrote:
> > On Wed, Oct 28, 2015 at 06:48:41PM +0100, Eric Auger wrote:
> >> On 10/28/2015 06:37 PM, Alex Williamson wrote:
> >>> Ok, so with hopefully correcting my understand of what this does, isn't
> >>> this effectively the same:
> >>>
> >>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> >>> index 57d8c37..7db4f5a 100644
> >>> --- a/drivers/vfio/vfio_iommu_type1.c
> >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> >>> @@ -403,13 +403,19 @@ static void vfio_remove_dma(struct vfio_iommu *iommu, stru
> >>>  static unsigned long vfio_pgsize_bitmap(struct vfio_iommu *iommu)
> >>>  {
> >>>         struct vfio_domain *domain;
> >>> -       unsigned long bitmap = PAGE_MASK;
> >>> +       unsigned long bitmap = ULONG_MAX;
> >>>  
> >>>         mutex_lock(&iommu->lock);
> >>>         list_for_each_entry(domain, &iommu->domain_list, next)
> >>>                 bitmap &= domain->domain->ops->pgsize_bitmap;
> >>>         mutex_unlock(&iommu->lock);
> >>>  
> >>> +       /* Some comment about how the IOMMU API splits requests */
> >>> +       if (bitmap & ~PAGE_MASK) {
> >>> +               bitmap &= PAGE_MASK;
> >>> +               bitmap |= PAGE_SIZE;
> >>> +       }
> >>> +
> >>>         return bitmap;
> >>>  }
> >> Yes, to me it is indeed the same
> >>>  
> >>> This would also expose to the user that we're accepting PAGE_SIZE, which
> >>> we weren't before, so it was not quite right to just let them do it
> >>> anyway.  I don't think we even need to get rid of the WARN_ONs, do we?
> >>> Thanks,
> >>
> >> The end-user might be afraid of those latter. Personally I would get rid
> >> of them but that's definitively up to you.
> > 
> > I think Alex's point is that the WARN_ON's won't trigger with this patch,
> > because he clears those lower bits in the bitmap.
> ah yes sure!

The WARN_ON triggers when the IOMMU mask is greater than PAGE_SIZE,
which means we can't operate on the IOMMU with PAGE_SIZE granularity,
which we do in a couple places.  So I think the WARN_ON is actually
valid for the code and won't trigger for you now that the IOMMU mask is
always at least ~PAGE_MASK if we can use the IOMMU at anything less than
PAGE_SIZE granularity.  Thanks,

Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Eric Auger <eric.auger@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>,
	eric.auger@st.com, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	suravee.suthikulpanit@amd.com, christoffer.dall@linaro.org,
	linux-kernel@vger.kernel.org, patches@linaro.org
Subject: Re: [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size
Date: Wed, 28 Oct 2015 12:15:13 -0600	[thread overview]
Message-ID: <1446056113.8018.419.camel@redhat.com> (raw)
In-Reply-To: <56310D39.6090500@linaro.org>

On Wed, 2015-10-28 at 19:00 +0100, Eric Auger wrote:
> On 10/28/2015 06:55 PM, Will Deacon wrote:
> > On Wed, Oct 28, 2015 at 06:48:41PM +0100, Eric Auger wrote:
> >> On 10/28/2015 06:37 PM, Alex Williamson wrote:
> >>> Ok, so with hopefully correcting my understand of what this does, isn't
> >>> this effectively the same:
> >>>
> >>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> >>> index 57d8c37..7db4f5a 100644
> >>> --- a/drivers/vfio/vfio_iommu_type1.c
> >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> >>> @@ -403,13 +403,19 @@ static void vfio_remove_dma(struct vfio_iommu *iommu, stru
> >>>  static unsigned long vfio_pgsize_bitmap(struct vfio_iommu *iommu)
> >>>  {
> >>>         struct vfio_domain *domain;
> >>> -       unsigned long bitmap = PAGE_MASK;
> >>> +       unsigned long bitmap = ULONG_MAX;
> >>>  
> >>>         mutex_lock(&iommu->lock);
> >>>         list_for_each_entry(domain, &iommu->domain_list, next)
> >>>                 bitmap &= domain->domain->ops->pgsize_bitmap;
> >>>         mutex_unlock(&iommu->lock);
> >>>  
> >>> +       /* Some comment about how the IOMMU API splits requests */
> >>> +       if (bitmap & ~PAGE_MASK) {
> >>> +               bitmap &= PAGE_MASK;
> >>> +               bitmap |= PAGE_SIZE;
> >>> +       }
> >>> +
> >>>         return bitmap;
> >>>  }
> >> Yes, to me it is indeed the same
> >>>  
> >>> This would also expose to the user that we're accepting PAGE_SIZE, which
> >>> we weren't before, so it was not quite right to just let them do it
> >>> anyway.  I don't think we even need to get rid of the WARN_ONs, do we?
> >>> Thanks,
> >>
> >> The end-user might be afraid of those latter. Personally I would get rid
> >> of them but that's definitively up to you.
> > 
> > I think Alex's point is that the WARN_ON's won't trigger with this patch,
> > because he clears those lower bits in the bitmap.
> ah yes sure!

The WARN_ON triggers when the IOMMU mask is greater than PAGE_SIZE,
which means we can't operate on the IOMMU with PAGE_SIZE granularity,
which we do in a couple places.  So I think the WARN_ON is actually
valid for the code and won't trigger for you now that the IOMMU mask is
always at least ~PAGE_MASK if we can use the IOMMU at anything less than
PAGE_SIZE granularity.  Thanks,

Alex


  reply	other threads:[~2015-10-28 18:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 13:12 [RFC] vfio/type1: handle case where IOMMU does not support PAGE_SIZE size Eric Auger
2015-10-28 13:12 ` Eric Auger
2015-10-28 15:37 ` Will Deacon
2015-10-28 15:37   ` Will Deacon
2015-10-28 15:37   ` Will Deacon
2015-10-28 16:27 ` Alex Williamson
2015-10-28 16:27   ` Alex Williamson
2015-10-28 17:10   ` Eric Auger
2015-10-28 17:10     ` Eric Auger
2015-10-28 17:37     ` Alex Williamson
2015-10-28 17:37       ` Alex Williamson
2015-10-28 17:37       ` Alex Williamson
2015-10-28 17:48       ` Eric Auger
2015-10-28 17:48         ` Eric Auger
2015-10-28 17:48         ` Eric Auger
2015-10-28 17:55         ` Will Deacon
2015-10-28 17:55           ` Will Deacon
2015-10-28 18:00           ` Eric Auger
2015-10-28 18:00             ` Eric Auger
2015-10-28 18:00             ` Eric Auger
2015-10-28 18:15             ` Alex Williamson [this message]
2015-10-28 18:15               ` Alex Williamson
2015-10-28 18:15               ` Alex Williamson
2015-10-28 17:14   ` Will Deacon
2015-10-28 17:14     ` Will Deacon
2015-10-28 17:17     ` Eric Auger
2015-10-28 17:17       ` Eric Auger
2015-10-28 17:17       ` Eric Auger
2015-10-28 17:28     ` Alex Williamson
2015-10-28 17:28       ` Alex Williamson
2015-10-28 17:28       ` Alex Williamson
2015-10-28 17:41       ` Eric Auger
2015-10-28 17:41         ` Eric Auger
2015-10-28 17:41         ` Eric Auger

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=1446056113.8018.419.camel@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=eric.auger@linaro.org \
    --cc=eric.auger@st.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@linaro.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.