12:22:51 WHT.. can some company be named as illumos ? isn't illumos protected as international brand.. or it does not matter for Ltd. ...https://illumos.co/product/omnistain-trial/ 13:01:01 my understanding is that it is only protected when it comes to computer operating systems 13:01:34 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 14:27:21 hi, https://www.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 14:28:26 www.illumos.org/ is fine, but /issues is painfully slow no matter where i connect from so far 14:33:41 Hmm, I'm seeing a bit of slowness. It's probably another AI scraping ddos. 16:38:03 so i think i'm done with iommu bugs for now :) 16:38:15 managed to finally get that system booted... 17:12:32 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 17:14:08 I'd be especially surprised if the illumos trademark was registered in Hong Kong, where that company is 18:52:31 jbk: nice work... how many more patches besides what you've sent out for review? 19:37:50 sommerfeld: a few... a couple are things that probably need more discussion 19:38:31 e.g. using an IPI as an IOMMU interrupt (which currently we just use to report errors from the IOMMU) 19:39:58 heh 19:40:19 let's try that again (since I think it got missed in the netsplit) 19:40:54 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) 19:43:04 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) 19:43:24 that also seems like it could be insidious to anyone who would ever hit it as well 19:45:19 but i figure I'd start with the pretty obvious ones and knock those out 20:22:22 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 20:23:26 (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) 20:23:47 and then adjusting the iommu code to properly track things 20:24:39 (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) 20:27:29 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 20:27:42 but I know it confused me and rmustacc when we were talking at cross purposes about it for a while 20:41:48 one thing that could be a bit confusing is that there is also a concept of a domain with the intel iommu 20:42:09 where that's a group of devices (usually either 'all of them' or just 1 device) that share mappings 20:42:37 and they're also assigned integral ids 20:43:07 (I thought I filed a ticket in fact to use id spaces instead of directly usign a vmem arena to assign those) 21:06:10 jbk: was just looking through what you'd filed recently and saw mention of vmem->idspace at least in passing. 21:09:16 ok.. i couldn't remember if it made it through since that was when redmine was having some issues... 21:09:32 it's not needed to make things work, just seemed like it'd be a nice improvement 21:24:28 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... 21:24:37 e.g. we might want a 'white list' of known good systems 21:25:06 or a way to specify certain behaviors on system (e.g. maybe we want interrupt remapping and not DMA remapping) 21:25:20 at least as a way to maybe eventually get to where it can be enabled by default 21:39:58 https://www.illumos.org/issues/17701 looks like the vmem -> id_space issue 21:39:59 → FEATURE 17701: Intel IOMMU could use id_space_ts for domain ids. (New) 22:23:49 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? 22:24:13 it isn't even rough to implement such a thing talking to ispell/etc. down a pipe, but I'd really rather not :) 22:24:55 "hunspell" seems to be the current ispell-a-like, and it does not do it natively 22:45:45 also.. i'm open to suggestions on #17698 -- I need to walk through all the indirection for DMA commands 22:46:21 i think the prealloc is for a single allocation 22:47:16 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 22:50:18 (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... 22:50:57 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) 22:53:28 (probably not that relevant, but I wouldn't be surprised if dispatching from a switch statement was faster than indirection through a function pointer 23:07:20 jbk: when spectre mitigations are enabled and indirect calls go through thunks, definitely. 23:09:35 linux added some really atrocious hacks to minimize indirect calls 23:10:49 look at include/linux/indirect_call_wrapper.h in the linux kernel source. 23:11:34 INDIRECT_CALL_1(f, f1, ...) through INDIRECT_CALL_4(f, f4, f3, f2, f1, ...) 23:11:50 where the body of _1 is likely(f == f1) ? f1(__VA_ARGS__) : f(__VA_ARGS__); 23:14:29 plus INDIRECT_CALL_INET which is defined differently depending on which of IPv4 and IPv6 or both are configured.. 23:15:23 "this function pointer is likely to point to f1, f2, f3, or f4; avoid the indirect call if it matches one of them". 23:17:09 back to us, my vague sense is that sparc had a bunch more diversity in iommu implementation 23:26:47 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 23:43:07 the sparc mmu implementation was utterly disconnected from the x86 one 23:43:12 uh, iommu 23:43:36 no shared genetics that I ever discovered 23:44:23 also I think it was hierarchically sensible there, so devices were beneath the device that contained the iommu which controlled them 23:45:27 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 23:45:39 and just hooks into the ddi implementation