If I end up doing something at work with Rust in user space that is like actually needed by someone, these days I first write it in C and then rewrite it Rust.

It's just that with C you can touch anything, and thus it is extreme levels fast discover how systems do when you poke them.

In kernel things are obviously different as there is just one thing your tickling ;-)

I'm doing a small thingie to help out mutt with email using Zig. It's something i was going to do in any possible situation, so thought to spice it up like this. It's of scale that i can fully finish it and never look back zig again if i don't want to, and large enough so that i know if the language makes sense at all.

It's a bit similar case as lsiommu, i.e. scripts that have been making my life worse for over 10 years and now I'm "reimagining" them ;-)

This way I get those wiped away from my backlog and learn something new in the process.

#zig #mutt #email

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 :-)