All of lore.kernel.org
 help / color / mirror / Atom feed
* IOMMU detection via sysfs
@ 2017-03-22 11:06 Gabor Locsei
       [not found] ` <DB4PR07MB0701CD0B470B1B18ECF99D98E13C0-+uUz27+Iw09nNELNIBuVYjzdlHkvsOLVvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Gabor Locsei @ 2017-03-22 11:06 UTC (permalink / raw)
  To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Hello,

I have systems with IOMMU optionally enabled, and I would like to find a method to check these capabilities that doesn't rely on dmesg.
The evident problem is that dmesg eventually clear boot time messages so the relevant lines may just disappear.

Looks like there are sysfs entries that seem to be fit for this purpose. 

DMAR			The file /sys/firmware/acpi/tables/DMAR exists. (This file exists on every lab node.)
IOMMU			The directory /sys/devices/virtual/iommu/ exists and there are dmar0, etc device subdirectories in it

I have looked into the ACPI DMAR tables with iasl, but they look the same regardless of the cmdline iommu settings.
The question is, provided that the platform has ACPI, is it safe to rely on sysfs, is the above enough to prove that IOMMU is available? The oldest kernel version to verify against is 3.10.0 from RHEL.

Thanks!

best regards,
Gabor

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: IOMMU detection via sysfs
       [not found] ` <DB4PR07MB0701CD0B470B1B18ECF99D98E13C0-+uUz27+Iw09nNELNIBuVYjzdlHkvsOLVvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2017-03-22 14:39   ` Alex Williamson
  0 siblings, 0 replies; 2+ messages in thread
From: Alex Williamson @ 2017-03-22 14:39 UTC (permalink / raw)
  To: Gabor Locsei; +Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

On Wed, 22 Mar 2017 11:06:47 +0000
Gabor Locsei <gabor.locsei-IzeFyvvaP7pWk0Htik3J/w@public.gmane.org> wrote:

> Hello,
> 
> I have systems with IOMMU optionally enabled, and I would like to find a method to check these capabilities that doesn't rely on dmesg.
> The evident problem is that dmesg eventually clear boot time messages so the relevant lines may just disappear.
> 
> Looks like there are sysfs entries that seem to be fit for this purpose. 
> 
> DMAR			The file /sys/firmware/acpi/tables/DMAR exists. (This file exists on every lab node.)
> IOMMU			The directory /sys/devices/virtual/iommu/ exists and there are dmar0, etc device subdirectories in it
> 
> I have looked into the ACPI DMAR tables with iasl, but they look the same regardless of the cmdline iommu settings.
> The question is, provided that the platform has ACPI, is it safe to rely on sysfs, is the above enough to prove that IOMMU is available? The oldest kernel version to verify against is 3.10.0 from RHEL.

DMAR is a firmware table, it's present so long as VT-d is enabled in
the BIOS, irrespective of whether the IOMMU is enabled in the kernel.
The IOMMU sysfs support was added exactly for this purpose (I tend to
prefer reference via /sys/class/iommu).

IOMMU sysfs support was added in v3.17, but note that the RHEL version
of v3.10 is a moving target, not a fixed point in time.  This support
was added in the RHEL 7.1 kernel.  Thanks,

Alex

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-03-22 14:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-22 11:06 IOMMU detection via sysfs Gabor Locsei
     [not found] ` <DB4PR07MB0701CD0B470B1B18ECF99D98E13C0-+uUz27+Iw09nNELNIBuVYjzdlHkvsOLVvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-03-22 14:39   ` Alex Williamson

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.