Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1198902 > unrolled thread

Re: [PATCH 2/2] iommu/vt-d: Report superpage support in sysfs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/2] iommu/vt-d: Report superpage support in sysfs Joerg Roedel <joro@8bytes.org> - 2015-08-03 16:40 +0200
    Re: [PATCH 2/2] iommu/vt-d: Report superpage support in sysfs David Woodhouse <dwmw2@infradead.org> - 2015-08-03 16:40 +0200
    Re: [PATCH 2/2] iommu/vt-d: Report superpage support in sysfs Alex Williamson <alex.williamson@redhat.com> - 2015-08-03 17:10 +0200

#1198902 — Re: [PATCH 2/2] iommu/vt-d: Report superpage support in sysfs

On Tue, Jul 14, 2015 at 03:25:04PM -0600, Alex Williamson wrote:
> We already have the VT-d capability register printed raw, but it
> typically involves a trip to the code or the spec to figure out
> whether superpages are supported.  Make this easier with "2M_pages"
> and "1G_pages" sysfs entries that clearly report Y/N.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/iommu/intel-iommu.c |   22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)

Can we make this a generic entry for all iommu types and export a
pagesize bitmap instead?


	Joerg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1198905

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2015-08-03 at 16:30 +0200, Joerg Roedel wrote:
> On Tue, Jul 14, 2015 at 03:25:04PM -0600, Alex Williamson wrote:
> > We already have the VT-d capability register printed raw, but it
> > typically involves a trip to the code or the spec to figure out
> > whether superpages are supported.  Make this easier with "2M_pages"
> > and "1G_pages" sysfs entries that clearly report Y/N.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> >  drivers/iommu/intel-iommu.c |   22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> 
> Can we make this a generic entry for all iommu types and export a
> pagesize bitmap instead?

As long as we don't further entrench the current abomination of
advertising all page sizes which are a multiple of 4KiB, which we do to
work around KVM brain damage.

I think I did manage to fix that once, with a patch that would abuse pg
->freelist when tearing down the mappings from KVM. Which ISTR was the
main problem with fixing the API. I'll see if I can recover enough of
my addled memory and revive that...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[toc] | [prev] | [next] | [standalone]

#1198928

On Mon, 2015-08-03 at 16:30 +0200, Joerg Roedel wrote:
> On Tue, Jul 14, 2015 at 03:25:04PM -0600, Alex Williamson wrote:
> > We already have the VT-d capability register printed raw, but it
> > typically involves a trip to the code or the spec to figure out
> > whether superpages are supported.  Make this easier with "2M_pages"
> > and "1G_pages" sysfs entries that clearly report Y/N.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> >  drivers/iommu/intel-iommu.c |   22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> 
> Can we make this a generic entry for all iommu types and export a
> pagesize bitmap instead?

Are you suggesting a bitmap in order to have a consistent interface,
independently implemented by each IOMMU driver, or are you suggesting a
common interface implemented by iommu_ops.pgsize_bitmap?  The latter is
pretty well broken already.  It can't represent different IOMMU hardware
units having different capabilities, and it's broken by drivers like
intel-iommu that don't expose native hardware page sizes, but anything
that can be broken down into native hardware page size, so ~(4k-1).

Programatically, a bitmap is a concise way to expose multiple page
sizes, but for human consumption, it's not an ideal solution.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web