[PATCH 0/2] iommu/vt-d: Additional sysfs entries

[PATCH 0/2] iommu/vt-d: Additional sysfs entries

[Alex Williamson]

A couple additional sysfs entries for intel-iommu.  The number of
domains supported and superpages available can all be picked from the
value of the VT-d capability register that we already print, but it's
much more accessible when split out to human readable values.  The
domain IDs usage makes testing for leaks far more accessible.  Older
hardware that only supports an 8-bit domain ID might stumble over
some leaks in testing, but newer hardware with 16-bit domain IDs may
hide issues for a long time.  Besides, it's interesting, geeky data.
Thanks,

Alex

---

Alex Williamson (2):
      iommu/vt-d: Report domain usage in sysfs
      iommu/vt-d: Report superpage support in sysfs


 drivers/iommu/intel-iommu.c |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

[PATCH 1/2] iommu/vt-d: Report domain usage in sysfs

[Alex Williamson]

Debugging domain ID leakage typically requires long running tests in
order to exhaust the domain ID space or kernel instrumentation to
track the setting and clearing of bits.  A couple trivial intel-iommu
specific sysfs extensions make it much easier to expose the IOMMU
capabilities and current usage.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
 drivers/iommu/intel-iommu.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0649b94..560afc0 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4449,11 +4449,32 @@ static ssize_t intel_iommu_show_ecap(struct device *dev,
 }
 static DEVICE_ATTR(ecap, S_IRUGO, intel_iommu_show_ecap, NULL);
 
+static ssize_t intel_iommu_show_ndoms(struct device *dev,
+				      struct device_attribute *attr,
+				      char *buf)
+{
+	struct intel_iommu *iommu = dev_get_drvdata(dev);
+	return sprintf(buf, "%ld\n", cap_ndoms(iommu->cap));
+}
+static DEVICE_ATTR(domains_supported, S_IRUGO, intel_iommu_show_ndoms, NULL);
+
+static ssize_t intel_iommu_show_ndoms_used(struct device *dev,
+					   struct device_attribute *attr,
+					   char *buf)
+{
+	struct intel_iommu *iommu = dev_get_drvdata(dev);
+	return sprintf(buf, "%d\n", bitmap_weight(iommu->domain_ids,
+						  cap_ndoms(iommu->cap)));
+}
+static DEVICE_ATTR(domains_used, S_IRUGO, intel_iommu_show_ndoms_used, NULL);
+
 static struct attribute *intel_iommu_attrs[] = {
 	&dev_attr_version.attr,
 	&dev_attr_address.attr,
 	&dev_attr_cap.attr,
 	&dev_attr_ecap.attr,
+	&dev_attr_domains_supported.attr,
+	&dev_attr_domains_used.attr,
 	NULL,
 };
 

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

[Alex Williamson]

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(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 560afc0..eb6e3f4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4468,6 +4468,26 @@ static ssize_t intel_iommu_show_ndoms_used(struct device *dev,
 }
 static DEVICE_ATTR(domains_used, S_IRUGO, intel_iommu_show_ndoms_used, NULL);
 
+static ssize_t intel_iommu_show_2M_pages(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct intel_iommu *iommu = dev_get_drvdata(dev);
+	return sprintf(buf, "%c\n", cap_super_page_val(iommu->cap) & 1 ?
+		       'Y' : 'N');
+}
+static DEVICE_ATTR(2M_pages, S_IRUGO, intel_iommu_show_2M_pages, NULL);
+
+static ssize_t intel_iommu_show_1G_pages(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct intel_iommu *iommu = dev_get_drvdata(dev);
+	return sprintf(buf, "%c\n", cap_super_page_val(iommu->cap) & 2 ?
+		       'Y' : 'N');
+}
+static DEVICE_ATTR(1G_pages, S_IRUGO, intel_iommu_show_1G_pages, NULL);
+
 static struct attribute *intel_iommu_attrs[] = {
 	&dev_attr_version.attr,
 	&dev_attr_address.attr,
@@ -4475,6 +4495,8 @@ static struct attribute *intel_iommu_attrs[] = {
 	&dev_attr_ecap.attr,
 	&dev_attr_domains_supported.attr,
 	&dev_attr_domains_used.attr,
+	&dev_attr_2M_pages.attr,
+	&dev_attr_1G_pages.attr,
 	NULL,
 };
 

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

[Joerg Roedel]

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

Re: [PATCH 1/2] iommu/vt-d: Report domain usage in sysfs

[Joerg Roedel]

On Tue, Jul 14, 2015 at 03:24:53PM -0600, Alex Williamson wrote:
> Debugging domain ID leakage typically requires long running tests in
> order to exhaust the domain ID space or kernel instrumentation to
> track the setting and clearing of bits.  A couple trivial intel-iommu
> specific sysfs extensions make it much easier to expose the IOMMU
> capabilities and current usage.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/iommu/intel-iommu.c |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)

Applied, thanks Alex.

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

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

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Alex Williamson]

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