hrm.. do addrconf interfaces show up with <IFNAME>/? names (for zones) in ipadm outside of smartos (i.e. not sure if this is an upstream behavior or smartos specific)

?

the ipv4 show up as net0/_a

but ipv6 are net0/?

[illumos-gate] 17638 Update AMD microcode to 20250729 -- Andy Fiddaman <illumos⊙fn>

guys, I see empty otput here: src.illumos.org/source/xref/illumos…realpath.c?r=b30d1939?r=b30d1939#45

does it work?

we don't have a way to manipulate EFI boot vars for bhyve VMs, do we?

denk: remove that last '?r=.....' (note it's doubled)

some opengrok bug unfortunately

jbk: it works, thanks

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

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

install it somewhere and we can help to break it for you :)

i have to write it first :)

[illumos-gate] 17674 cxgbe: stack overflow in t4_eth_tx() -- Andy Fiddaman <illumos⊙fn>

jbk: I think we can change EFI stuff in VMs, just not smoothly? tsoome knows

something about it gets marshalled to some file and you can change it, maybe?

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

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

bhyve VMs on OmniOS use the persistent flash file too,

but if a VM is started without that, the UEFI firmware uses a file in the ESP instead.

and we have a utility to manipulate the files, yes.. I'll grab a link

oh, we do? neat. I thought that was the missing bit

Well we don't have one that runs inside an illumos vm, if that's what you mean.

I thought we didn't have one at all

yeah, i know we don't expose the UEFI vars either in the kernel (let alone userland) currently

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

s/open/option

`zadm` even has an option to bring up a boot device selection TUI

jbk: you could implement a /system/efi/<something>?

I think the little pseudo-fs framework I forgot the name of isn't so bad

the one objfs and ctfs and such use

gfs I think?

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

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

ahh here it is: uefi.org/specs/UEFI/2.11/02_Overview.html#x64-platforms

(down a bit for the runtime requirements)

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)

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.

oh i was referring to rich's question about exposing vars to the kernel

andyf: but yeah, that's exactly what I was looking for for manipulating them on the HV side

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

err we shouldn't be clobbering it