lsiommu provides now also json output:

❯ build/lsiommu | head -10
Group 000 Address 0000:00:07.1 Class 060400 ID 8086:9a25 Revision 01
Group 001 Address 0000:00:07.0 Class 060400 ID 8086:9a23 Revision 01
Group 002 Address 0000:00:02.0 Class 030000 ID 8086:9a49 Revision 01
Group 003 Address 0000:00:00.0 Class 060000 ID 8086:9a14 Revision 01
Group 004 Address 0000:00:04.0 Class 118000 ID 8086:9a03 Revision 01
Group 005 Address 0000:00:0a.0 Class 118000 ID 8086:9a0d Revision 01
Group 006 Address 0000:00:0d.0 Class 0c0330 ID 8086:9a13 Revision 01
Group 006 Address 0000:00:0d.2 Class 0c0340 ID 8086:9a1b Revision 01
Group 007 Address 0000:00:0e.0 Class 010400 ID 8086:9a0b Revision 00
Group 008 Address 0000:00:14.0 Class 0c0330 ID 8086:a0ed Revision 20

~/work/github.com/puavo-org/lsiommu master
❯ build/lsiommu --style json | head -10
{
        "iommu_groups": [{
                        "id":   0,
                        "devices":      [{
                                        "address":      "0000:00:07.1",
                                        "class":        "060400",
                                        "vendor":       "8086",
                                        "device":       "9a25",
                                        "revision":     "01"
                                }]

better not to tag 1.0.0 yet to leave room for command-line interface and output formatting tweaks although now it is “feature complete”.

#linux #iommu

@kidney with I added it together with sysfs discovery:

❯ build/lsiommu -h
Usage: build/lsiommu [-h]
Lists IOMMU groups and their associated PCI devices.
This version was compiled for sysfs discovery.

-h, --help Print help and exit

@kidney actually i somehow manage forgot to implement that. i'll add it back with sysfs support :-) thanks for notifying

this felt super counter-productive:

https://github.com/puavo-org/lsiommu/blob/master/udev.c

does libudev have mechanism to get directly a packed representation?

#linux #udev #pci

@ge0rg and develop some utility modules like https://github.com/puavo-org/lsiommu/blob/master/down.c, https://github.com/puavo-org/lsiommu/blob/master/strbuf.c and https://github.com/puavo-org/lsiommu/blob/master/radix.c for the stuff that i'm working on.

@ge0rg it does not do whole alot that you could not do with trivial scripting. i had such a script for 10 years with bash and python but i wanted to consolidate that into C program to get a baseline that can be extended to do more complex things in future. and i needed to learn to use libudev properly for something more serious so this was a good exercise to test run it (my original script traversed sysfs).

@ge0rg in technical sense you can already do what my tool does with lspci -vmm, i.e. get IOMMU groups:

❯ lspci -vmm|head -25
Slot: 00:00.0
Class: Host bridge
Vendor: Intel Corporation
Device: 11th Gen Core Processor Host Bridge/DRAM Registers
SVendor: Hewlett-Packard Company
SDevice: 11th Gen Core Processor Host Bridge/DRAM Registers
Rev: 01
ProgIf: 00
IOMMUGroup: 3

Slot: 00:02.0
Class: VGA compatible controller
Vendor: Intel Corporation
Device: TigerLake-LP GT2 [Iris Xe Graphics]
SVendor: Hewlett-Packard Company
SDevice: TigerLake-LP GT2 [Iris Xe Graphics]
Rev: 01
ProgIf: 00
IOMMUGroup: 2

Slot: 00:04.0
Class: Signal processing controller
Vendor: Intel Corporation
Device: TigerLake-LP Dynamic Tuning Processor Participant
SVendor: Hewlett-Packard Company
# ...

But this is not very productive if you are interested IOMMU groups first and PCI devices second.

After a bit of tuning I ended up to "lsusb style" dump:

❯ lsiommu
Group 000 00:07.1 Class 060400: Vendor 8086 Device 9a25 [8086:9a25] (rev 01)
Group 001 00:07.0 Class 060400: Vendor 8086 Device 9a23 [8086:9a23] (rev 01)
Group 002 00:02.0 Class 030000: Vendor 8086 Device 9a49 [8086:9a49] (rev 01)
Group 003 00:00.0 Class 060000: Vendor 8086 Device 9a14 [8086:9a14] (rev 01)
Group 004 00:04.0 Class 118000: Vendor 8086 Device 9a03 [8086:9a03] (rev 01)
Group 005 00:0a.0 Class 118000: Vendor 8086 Device 9a0d [8086:9a0d] (rev 01)
Group 006 00:0d.0 Class 0c0330: Vendor 8086 Device 9a13 [8086:9a13] (rev 01)
Group 006 00:0d.2 Class 0c0340: Vendor 8086 Device 9a1b [8086:9a1b] (rev 01)
Group 007 00:0e.0 Class 010400: Vendor 8086 Device 9a0b [8086:9a0b] (rev 00)
Group 008 00:14.0 Class 0c0330: Vendor 8086 Device a0ed [8086:a0ed] (rev 20)
Group 008 00:14.2 Class 050000: Vendor 8086 Device a0ef [8086:a0ef] (rev 20)
Group 009 00:14.3 Class 028000: Vendor 8086 Device a0f0 [8086:a0f0] (rev 20)
Group 010 00:15.0 Class 0c8000: Vendor 8086 Device a0e8 [8086:a0e8] (rev 20)
Group 011 00:16.0 Class 078000: Vendor 8086 Device a0e0 [8086:a0e0] (rev 20)
Group 012 00:1d.0 Class 060400: Vendor 8086 Device a0b0 [8086:a0b0] (rev 20)
Group 013 00:1f.0 Class 060100: Vendor 8086 Device a082 [8086:a082] (rev 20)
Group 013 00:1f.3 Class 040100: Vendor 8086 Device a0c8 [8086:a0c8] (rev 20)
Group 013 00:1f.4 Class 0c0500: Vendor 8086 Device a0a3 [8086:a0a3] (rev 20)
Group 013 00:1f.5 Class 0c8000: Vendor 8086 Device a0a4 [8086:a0a4] (rev 20)
Group 014 55:00.0 Class 010802: Vendor 144d Device a808 [144d:a808] (rev 00)

I don't want to stringify classes or other elements right now because this output always fits the screen, which matters to me.

@kidney not whole a lot

I wonder if Azure has somewhere a place where you can upload endorsement certificates?

This would be for testing Himmelblau on a VM and for that use and purpose create a fake TPM vendor CA. AFAIK, Himmelblau does not yet sign anything with attestation keys but there will be a day when it will, so better to be prepared.

#himmelblau #azure #tpm

fixing up the sort algorithm mess, adding compile time option for sysfs scan (for e.g., supporting some Buildroot configurations) and perhaps --json and lsiommu should be good enough for 1.0.

It's quite light now with deps in all situations:

deps = [
dependency('argtable2'),
dependency('libudev'),
]

#linux #iommu #buildroot

fuck https://github.com/puavo-org/lsiommu/commit/23c7740709b5e288337dbe02853f897ee5eb07a0

i reworked PCI address representation which will allow to use radix sort for both cases:

https://github.com/puavo-org/lsiommu/commit/572ea9d86285f48afd0249dc32cea704e2d5512b

i guess it makes overall sense

... or actually totally unneeded given low amount of groups but it can be ;-)

derived radix sort from https://www.cubic.org/docs/radix.htm (because it is good fit for the purpose)

https://github.com/puavo-org/lsiommu #linux #iommu

@andrew it's quite painful system to use https://en.wikipedia.org/wiki/Troff

awesome, almost ready to ship :-)

this came out pretty nice and clean

❯ git ls-files
.tokeignore
CHANGELOG.md
LICENSE
Makefile
README.md
down.c
down.h
iommu.c
iommu.h
log.c
log.h
lsiommu.1
main.c
main.h
meson.build
meson.options
strbuf.c
strbuf.h
util.h

#linux #iommu

first valgrind pass i tried also looked pretty decent:

==425020==
==425020== HEAP SUMMARY:
==425020==     in use at exit: 0 bytes in 0 blocks
==425020==   total heap usage: 2,143 allocs, 2,143 frees, 786,679 bytes allocated
==425020==
==425020== All heap blocks were freed -- no leaks are possible
==425020==
==425020== For lists of detected and suppressed errors, rerun with: -s
==425020== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

was a bit surprise tho :-)

❯ wc -l *.c *.h
  317 iommu.c
   31 log.c
   70 main.c
   32 teardown.c
   26 iommu.h
   16 log.h
   11 main.h
   20 teardown.h
  523 total

Not too bad considering that iommu.c has a heap tree and radix sort implementation (I dislike qsort for anything really)

RE: https://social.kernel.org/objects/96e13d6c-6be2-4180-9bbc-f4e3fbd6a38b

Deps where "bookworm optimized", i.e. I used that debian version as the lowest common denominator for the deps.

#debian