00:09:56 hrm.. do addrconf interfaces show up with /? names (for zones) in ipadm outside of smartos (i.e. not sure if this is an upstream behavior or smartos specific) 00:09:59 ? 00:10:22 the ipv4 show up as net0/_a 00:10:34 but ipv6 are net0/? 12:58:59 [illumos-gate] 17638 Update AMD microcode to 20250729 -- Andy Fiddaman 17:59:11 guys, I see empty otput here: https://src.illumos.org/source/xref/illumos-gate/usr/src/contrib/ast/src/lib/libast/comp/realpath.c?r=b30d1939?r=b30d1939#45 17:59:20 does it work? 18:26:06 we don't have a way to manipulate EFI boot vars for bhyve VMs, do we? 18:26:19 denk: remove that last '?r=.....' (note it's doubled) 18:26:29 some opengrok bug unfortunately 18:35:57 jbk: it works, thanks 18:38:00 i've entertained the thought of writing an opengrok clone in rust (there are libraries that create a similar sort of index that opengrok uses (same concept, not same format)) 18:39:20 if only because of needing an app server (e.g. tomcat)... plus it seems like the java implementation can take a rather large amount of memory when indexing 18:39:49 install it somewhere and we can help to break it for you :) 18:48:56 i have to write it first :) 20:25:33 [illumos-gate] 17674 cxgbe: stack overflow in t4_eth_tx() -- Andy Fiddaman 20:42:34 jbk: I think we can change EFI stuff in VMs, just not smoothly? tsoome knows 20:42:48 something about it gets marshalled to some file and you can change it, maybe? 21:09:09 the 'upstream' bhyve roms (like the ovmf ones) have a separate file that IIUC emulates a flash device (and possibly what UEFI refers to as UFS which doesn't appear to be related to any unix-y UFS, but something flash related)... but ISTR that our bhyve isn't the same as the 'upstream' one, but I also don't know how or why 21:12:20 (i've been having to write some UEFI applications, and it'd be nice to be able to easily run them w/ bhyve for testing and such) 21:18:13 bhyve VMs on OmniOS use the persistent flash file too, 21:19:04 but if a VM is started without that, the UEFI firmware uses a file in the ESP instead. 21:19:57 and we have a utility to manipulate the files, yes.. I'll grab a link 21:20:19 oh, we do? neat. I thought that was the missing bit 21:21:01 Well we don't have one that runs inside an illumos vm, if that's what you mean. 21:21:10 I thought we didn't have one at all 21:21:33 yeah, i know we don't expose the UEFI vars either in the kernel (let alone userland) currently 21:21:40 https://github.com/citrus-it/uefivars can manage the VM's persistent UEFI variables file that's linked into the VM via the "bootvars" configuration open 21:21:46 s/open/option 21:22:13 `zadm` even has an option to bring up a boot device selection TUI 21:22:23 jbk: you could implement a /system/efi/? 21:22:32 I think the little pseudo-fs framework I forgot the name of isn't so bad 21:22:39 the one objfs and ctfs and such use 21:22:48 gfs I think? 21:24:33 the only thing is aside from annotating the functions as msabi (some of the UEFI headers might do that already), ISTR there are certain other things we'd need to do surrounding any UEFI runtime calls 21:25:09 https://paste.omnios.org/?57f194aafd4ee4aa#8FTboYwRMZZqVefrwP7NjPfBYqDdrTw2CuKjb5TCogq9 21:25:22 e.g. I think there can be only 1 caller at a time, so there'd need to be a mutex, but I thought i read something about some other bits around CPU state that might have implications that'd need to be considered 21:29:38 ahh here it is: https://uefi.org/specs/UEFI/2.11/02_Overview.html#x64-platforms 21:29:53 (down a bit for the runtime requirements) 21:30:35 I don't know offhand if any of those would require special handling on our part, or if we already meet all of that (aside from the calling convention, which should be handled by annotating in the compiler for gcc or clang) 21:31:02 I think we're talking slightly at cross purposes, but you can definitely get a bhyve VM to present the persistent variable store, and inspect/manipulate it from outside the VM, which will make testing easier. 21:32:04 oh i was referring to rich's question about exposing vars to the kernel 21:32:24 andyf: but yeah, that's exactly what I was looking for for manipulating them on the HV side 21:36:06 (for support in the kernel, we'd just need the address of the RT table... which I think we might have... and be sure we don't clobber the UEFI RT memory -- presumably we should be, but i've not looked to know for sure) 21:36:29 err we shouldn't be clobbering it