tsoome: so for reasons I don't understand creating the isa device, vgatext, and hv_vmbus devices seems to avoid the problem (despite none of them using that physical address)

bug in the hypervisor?

i don't know..

just when i skipped over that, things booted enough I could see we weren't attachign the devices we need for gen2 vms

so I was able to see it was because the ACPI device ID for the vmbus had changed (again)

(it still need to be upstreamed, but us as well as omnios all have the hyper-v support)

if this really is it, it will annoy me for reasons beyond the immedate bug

as we treat ACPI as a bolt on enumerator of last resort

"UEFI & Synthetic Video: Instead of a legacy VGA adapter, Gen 2 VMs use a synthetic frame buffer (via the VMBus) and UEFI native graphics. This requires the OS to support UEFI and VMBus drivers out of the box"

"Because Gen 2 VMs boot strictly via UEFI and require VMBus integration for basic functions (like keyboard, mouse, and storage), the guest operating system must have the Hyper-V integration components/Linux Integration Services (LIS) built-in to be fully functional." -- or FreeBSD IS or in our case IIS:)

"Because emulated hardware like ISA bridges and IDE controllers is gone, you instead interact with synthetic devices mapped directly to the VMBus (e.g., synthetic network adapter, synthetic SCSI controller, synthetic video)."

Does it mean, the vmbus needs to be set up earlier?

what I'm wonering (having slept on it).. the acpidev driver is what enumerates the vmbus driver

(this is the part I still feel we do wrong and only explicitly enumerate specific allowed ACPI devices and ignore the rest vs. enumerate them and ignore specific ones when needed)

as a part of that, it creates the vgatext device node if it's gen2

along with the vmbus

(the EFI fb works fine -- there is a vmbus-based framebuffer driver in linux, but not freebsd... i've not ported it since it seems most useful for having more integration of a guest's graphical environment)

but the bug is/was the HID changed with win2025

so none of that was happening

in that link

what I'm wondering is since there was no framebuffer device in the tree if we were maybe then still trying to use the early boot stuff as a result (even if we shouldn't)

i know you did some work about using the efi framebuffer in the past (but can't remember when)... I wonder if maybe the person that hit that on actual hardware with some variant of that (prior to the stuff you did)

framebuffer is probably sort of an exception actually -- we do get memory mapped fb from firmware and as long as that mapping is not changed, we can still use it (as the address is known). The FB device [driver] will enter into the game when we want to change the mapping (via resolution change).

the frustating part is if we actually did enumerate and create devices in the device tree as the default (instead of the exception) for ACPI, it would have had 'VMBus' as a 'compatible' property, and we could have used device_aliases to bind the vmbus driver to the node (and probably avoid a lot of this special casing, or at least be able to confine it better... probably could create the necessary devices

during _init in the vmbus driver)

but ACPI used to be unreliable and hence used as a fallback?

probably initially, but it's been decades since that's been a real problem

and basically every other OS uses it on systems ~26 years old or newer

it also would probably mean changing the layout of the device tree which could be a problem

jbk... I wonder if fun-problems like this motivated $UTS/oxide to happen? :)

i suspect that is things like uefi and acpi are solutions because hw companies wanted to 'value add' without having to wait on microsoft (or for customers to upgrade to $LATEST)

also, it means they don't have to actually document how things work if it's just handled by both

unfortunately, most of us are stuck with them

so it'd be nice to take advantage of what's there

Agreed.

But the pain involved here.

i'm actually curious with that 'project patina' if it gets far enough along if it could be used to produce basically 'uefi for BIOS systems' (there used to be something like that with edkII but just trying to get that building with all of their bespoke build tooling is a bit of a pain)

it'd be a nice way to handle older non-UEFI systems

(assuming it works of course)

so we could just assume in the OS 'you have UEFI' (it'd simplify quite a few things around boot, and also allow for some other nice things)

"When in doubt, add another level of indirection." - L. Peterson

heh...

"project patina" seems like a good application of that.

well it's more i think replacing edkII with a rust implementation

so 'uefi written in rust'

(which also means less bespoke build tooling since rust and cargo has an understanding about cross compilation

or at least, i hope it means that

hrm.. does mac requery the LSO support after you down/up an interface

(e.g. you need to turn it off without modfying a driver.conf file, update a boot archive, reboot)

up/down an interface via IP?

yeah or ifconfig

So, mac is going to fix that basically at attach or maybe start time, but probably at mac_register.

But it's been a while.

Separately, IP is going to ask and cache that.

drat.. guess I just have to do the slow method :)

I was looking at that codepath a few months ago and I seem to recall there was at least something that could cause cache invalidation for checksum offload..

one moment..

i'm guessing why it's probably not plumbed up even as a private dladm property in any driver

err that's why

ip_verify_nce checks the cache; looks like it's handled when neighbor cache entries are deleted (conditional on nce_is_condemned == B_TRUE)

probably more for omnios for now, but it also appears that LSO isn't working in hyper-v either... guess I get to read up on NDIS :P

[illumos-gate] 18178 Makefile.master: .cc.a should PROCESS_COMMENT first, then AR -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 18188 loader: update .gitignore for userboot -- Toomas Soome <tsoome⊙mc>