WHT.. can some company be named as illumos ? isn't illumos protected as international brand.. or it does not matter for Ltd. ...illumos.co/product/omnistain-trial

my understanding is that it is only protected when it comes to computer operating systems

i could start an «illumos guitars» and probably not run afoul of the law. i wouldn't, because it would be hella rude, and also because i'm not a luthieuse, but

hi, illumos.org/account/register mostly throws 504. i managed to create an account and mx0.sea.illumos.org mailed me the activation link while the form was still loading/stuck

www.illumos.org/ is fine, but /issues is painfully slow no matter where i connect from so far

Hmm, I'm seeing a bit of slowness. It's probably another AI scraping ddos.

so i think i'm done with iommu bugs for now :)

managed to finally get that system booted...

I would be really surprised if anyone had actually registered a trademark to protect the illumos name, but even if they had Reinhilde is right that it would only apply to computer software not chemical & biological engineering

I'd be especially surprised if the illumos trademark was registered in Hong Kong, where that company is

jbk: nice work... how many more patches besides what you've sent out for review?

sommerfeld: a few... a couple are things that probably need more discussion

e.g. using an IPI as an IOMMU interrupt (which currently we just use to report errors from the IOMMU)

heh

let's try that again (since I think it got missed in the netsplit)

sommerfeld: there's a couple of changes that probably will need some more thought (e.g. how the IOMMU handles interrupts for itself, but that's just for reporting IOMMU errors, so you can get by without it)

and in the one case, i'm pretty sure i wasn't hitting this, but I noticed it was wrong, but not sure how to test (e.g. #17715)

that also seems like it could be insidious to anyone who would ever hit it as well

but i figure I'd start with the pretty obvious ones and knock those out

e.g. one of the other things is figuring out how much is needed for pci segment group support... i've done enough that seems to work for the intel iommu, but not sure if i'm just getting lucky w/ this hardware, or if there's other things needed for it to properly work

(it adds a 'pci-segment' property to the root complexes and populates the value, adds an acpica_get_sbdf() function that also returns the segment (though we could probably just rename acpica_get_bdf() and adjust the callers and have one function)

and then adjusting the iommu code to properly track things

(it adds an 'immu_devi' to a device with its BDF, the updated code also includes the segment, so it can properly find which iommu instance manages it)

jbk: fwiw, devicetree called the property "linux,pci-domain" I'm not sure to what degree the domain/segment terminology split exists in the world

but I know it confused me and rmustacc when we were talking at cross purposes about it for a while

one thing that could be a bit confusing is that there is also a concept of a domain with the intel iommu

where that's a group of devices (usually either 'all of them' or just 1 device) that share mappings

and they're also assigned integral ids

(I thought I filed a ticket in fact to use id spaces instead of directly usign a vmem arena to assign those)

jbk: was just looking through what you'd filed recently and saw mention of vmem->idspace at least in passing.

ok.. i couldn't remember if it made it through since that was when redmine was having some issues...

it's not needed to make things work, just seemed like it'd be a nice improvement

the other thing that might be worth thinking about is there's a lightly documented (in rootnex.conf) way to blacklist certain systems from using the IOMMU, but it might be useful to redo some of that...

e.g. we might want a 'white list' of known good systems

or a way to specify certain behaviors on system (e.g. maybe we want interrupt remapping and not DMA remapping)

at least as a way to maybe eventually get to where it can be enabled by default

illumos.org/issues/17701 looks like the vmem -> id_space issue

→ FEATURE 17701: Intel IOMMU could use id_space_ts for domain ids. (New)

emacs has `M-x ispell-comments-and-strings`, it does what it says and spellchecks comments and strings. Do any of you know of any other way to spell check only comments and strings?

it isn't even rough to implement such a thing talking to ispell/etc. down a pipe, but I'd really rather not :)

"hunspell" seems to be the current ispell-a-like, and it does not do it natively

also.. i'm open to suggestions on #17698 -- I need to walk through all the indirection for DMA commands

i think the prealloc is for a single allocation

which makes me think if dma_attr_seg < 2, the size should be capped at dma_attr_seg .. or it needs to be split up if the preallocation size is > dma_attr_seg

(I also wouldn't mind getting rid of some of the abstraction, since I doubt at this point if some 3rd IOMMU were to come out that we'd just give people an iommu driver binary to drop in vs. just rebuild the rootnex driver...

i find all of the multiple levels of indirection makes it harder to reason about things, and i think some of that at least probably made more sense 20+ years ago than it does today)

(probably not that relevant, but I wouldn't be surprised if dispatching from a switch statement was faster than indirection through a function pointer

jbk: when spectre mitigations are enabled and indirect calls go through thunks, definitely.

linux added some really atrocious hacks to minimize indirect calls

look at include/linux/indirect_call_wrapper.h in the linux kernel source.

INDIRECT_CALL_1(f, f1, ...) through INDIRECT_CALL_4(f, f4, f3, f2, f1, ...)

where the body of _1 is likely(f == f1) ? f1(__VA_ARGS__) : f(__VA_ARGS__);

plus INDIRECT_CALL_INET which is defined differently depending on which of IPv4 and IPv6 or both are configured..

"this function pointer is likely to point to f1, f2, f3, or f4; avoid the indirect call if it matches one of them".

back to us, my vague sense is that sparc had a bunch more diversity in iommu implementation

yeah, i could also see back in the day it may have been concern about more diversity in interrupt controllers and iommus on x86 than what ended up emerging... but 20+ years on, you have an APIC (or APIC in X2 mode, which is supposed to be almost completely identical except for the method of register access), and intel or amd iommu, and that's it

the sparc mmu implementation was utterly disconnected from the x86 one

uh, iommu

no shared genetics that I ever discovered

also I think it was hierarchically sensible there, so devices were beneath the device that contained the iommu which controlled them

if I recall, the x86 implementation as with most things doesn't care overly much about the tree-shape of the tree, because the hardware could be anywhere

and just hooks into the ddi implementation