tsoome_: so we take the virtual address to start allocating from in early boot (do_bsys*) from dboot in `bi_next_vaddr`, which appears to figure it out on its own. But we seem like we _probably_ used to assume that early boot allocated within MISC_VA_BASE,MISC_VA_SIZE (the range we `boot_mapin`)

do you know if I'm correct about MISC_VA? Do you know why we still mapin MISC_VA* (modulo unmapped pages), but that seems otherwise unspecial? do you know why, when we _do_ boot

_mapin we take `size` from `availrmem` but only actually _take_ those pages which are mapped

I find myself in the position where the x86 port maps it in (but doesn't seem to treat it as special to actually have a reason for that), and the arm64 port treats it specially for early allocations (mostly), but doesn't map boot memory that way

I don't know if correct is neither or both :)

so those constants are referring to before kernel text. I guess thats safe area because early boot allocations do happen from after kernel text+data+bss+modules and do_bsys is assuming everything after kernel + loaded bits is unused.

so it happens that the next free va that dboot hands to unix is within the MISC_VA range?

because otherwise how do we take over the mapping, if it's not in the range we `boot_mapin`?

[illumos-gate] 17623 vioscsi: panic during detach -- Hans Rosenfeld <rosenfeld⊙gho>

hrm..

it does seem like we could improve how installboot works (at least for EFI systems)

e.g. write out bootloaders to partition w/ a temp name and rename

(if the write fails for some reason, it currently leaves the disk unbootable)

also, perror() (err()/warn() and the like would be better.. esp for anyone using installboot from a script or such since it'll make it clearer the source of the error

that sounds nice.

(and using the *at() interfaces would simplify a lot of the code -- open /boot and the mount point and can do read()/write()/stat() relative to there

jbk: assuming there's enough extra space on the partition for more than one copy...

the zpool create -B is 256MiB, the loader binary is a bit under 600KiB

and there at least, you still have the old version

(or we could add an overwrite for such situations)

also, installboot seems inconsistent on using stdout vs stderr for errors...

(i've been fighting it for our stuff to install a few extra EFI binaries for diagnostic/troubleshooting purposes, and hitting all of this stuff as all of the assumptions of the default system being a BIOS booted system makes it more complicated than you would hope)

it might be worth making it easier in general if other distros wanted to do something similar (e.g. add memtest or the UEFI shell or something else)

[illumos-gate] 17684 bhyve/virtio-scsi: various small improvements -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 17685 bhyve/virtio-scsi: support for multiple targets -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 17686 bhyve/virtio-scsi: implement task management functions -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 17620 bhyve/virtio-scsi: support multiple backends -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 17619 bhyve/virtio-scsi: implement USCSI(4i) backend -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 17776 bhyve/virtio-scsi: make all I/O processing parameters configurable -- Hans Rosenfeld <rosenfeld⊙gho>