15:20:25 [illumos-gate] 18179 loader: make sure we do create fresh archive -- Toomas Soome 15:29:20 /win 1 15:43:38 what is the separation between illumos and distributions? I assumed it was something like the linux kernel where there is no userland whatsoever in the tree but looking in illumos-gate tree i see a libc folder? is that only kernel internal functions? 15:45:27 seti_: its more components than linux but less than FreeBSD so building does require a distribution but bundles many userland components together 15:46:06 I see, interesting! 16:39:05 seti_: among other differences, the stable ABI in illumos is via its dynamically-linked libc, not the syscall trap interface. 16:58:44 which has a lot of advantages despite statically linking the world being the en vogue thing 17:11:28 a lot of it comes down to "What did AT&T include in SVR4?" historically - the desktop & window system aren't there, but most classic Unix utilities are (with the notable exception of the compiler & related tools) 18:11:47 richlowe: would you think that after startup_vm() returns, kas.a_hat should produce reasonable output for ::htables (for comparison)? 18:13:41 I've managed (through a bit of a binary search) to figure out the vaddr that seems to produce a bad htable_t in clear_boot_mappings() that causes x86pte_inval() to get stuck in a look 18:17:53 sommerfeld: thats nice, I think linux is alone in having stable syscalls among all the OSes 18:18:43 i believe freebsd kinda/sorta does, but it's limited to a given version (so you might as well just link against libc or such and save yourself the headache) 18:21:08 tsoome: with the whole dance we do from UEFI->dboot->startup(), do we reuse the page table (and cr3) from UEFI at all, or do we build our own from the mappings passed in from loader? 18:22:57 or i guess do we reuse/manipulate the page tables UEFI has built before we've setup our own 18:23:22 jbk: yeah ive read it as well that they guarantee ABI stability within major versions 18:53:39 jbk dboot does call dboot_startkern.c:startup_kernel() which does build page tables and in dboot_grub.S we load top_page_table into cr3. 18:53:40 hrm... 18:54:02 so we don't re-use the tables UEFI sets up 18:54:13 no 18:56:34 ok 18:56:56 thats because UEFI tables are identity mapping, but we need to map our kernel (see build_page_tables()) 18:57:35 basically by the time we call clear_boot_mappings(), it's hitting a va that causes x86pte_inval() to go into an infinite loop 18:57:44 which suggests the entry is bad 18:57:54 so I'm trying to figure out how it could get in that state by then 18:58:14 1G/dump 18:58:18 oops 18:59:10 you can se ethe mapping with -B map_debug=true (enables call to dump_tables()) 19:02:08 i do wish microsoft had detailed release notes... i'd love to know what changed in hyper-v between win2022 and win2025 19:02:31 (the former works fine, the latter does not) 19:14:43 andyf: I imagine you're going to add _mdb_ks_ncpu _mdb_ks_ncpu_p2 etc? 19:15:03 or is there more to it than that? 19:15:19 re: #18181 (fenix?) 19:15:20 BUG 18181: mdb modules must stop hard-coding NCPU (In Progress) 19:15:20 ↳ https://www.illumos.org/issues/18181 19:16:01 (we're in a situation with arm I believe where technically it's _easy_ to out pace NCPU here in the future) 19:17:29 mdb already reads and populates _mdb_ks_ncpu from the target when it opens it so I've added an accessor and changed the modules that define _MACHDEP and make bad decisions to use it and allocate dynamically - or just do more selective reads from the target memory. 19:21:11 [illumos-gate] 18141 fix ksensor dip and unbind lifetimes -- Robert Mustacchi 19:21:11 [illumos-gate] 18142 ksensor_create can create dup minors -- Robert Mustacchi 19:21:11 [illumos-gate] 18143 ksensor should hold the underlying dip from open to close -- Robert Mustacchi 19:21:11 [illumos-gate] 18144 ksensor devfsadm plugin leaves behind stale devices -- Robert Mustacchi 19:27:20 andyf: MACHDEP is exciting for other stuff in the kernel 19:27:32 andyf: I learned with arm that sometimes we use MMU_PAGESHIT when we should use PAGESHIT 19:54:48 did you miss F on purpose?:P 19:57:09 hrmm.. the map seems reasonable 20:52:45 https://gist.github.com/jasonbking/1db1ca63ba3da8b3a30aac37cfd3a6ed 20:53:23 it's dieing when it's trying to clear va=2c04e000 and i can't see anything particularly special about that address... 21:09:32 so it is MA before kernel text (mapping ma=0x2c400000 va=0xfffffffffb800000 pte=0x2c4005e3 l=1 is kernel text segment) and thats why we try to clear that mapping. it does just hung while clearing attempt? 21:17:14 yeah.. it actually gets to the CAS_PTE() in x86pte_inval() and the VM hangs there (I thought it was maybe stuck in a loop, but after stepping after the lock cmpxchgq instruction, it dies 21:22:28 one we do with hyper-v is there is a page in the kernel called `hypercall_page` it serves the same purprose for hyper-v as it does for XEN 21:22:53 early on, we have to tell hyper-v the physical page of that 21:23:14 we use hat_getpfnum(kas.a_hat, hypercall_page) 21:23:55 we can't change it once set... 21:24:27 is it already set when this issue happens? 21:24:32 and the physical page is near(ish) to that.. but not very near (2c442000) 21:25:02 yes 21:26:17 mostly because the module gets loaded at that point and it initializes all of that... 21:44:17 is that vm using dynamic memory? 21:48:27 shouldn't be 21:52:50 just confirmed, it is not using dynamic memory 21:57:25 hrm.. i could see if I could move things so it's loaded after release_bootstrap() is called... the thing I'd be concerned though is then there's no input device until after the vmbus nexus driver is loaded and enumerates its children 21:57:34 (as the vmbus driver requires the hypercall interface) 21:57:57 if it was working ok on top of older windows and fails with newer, that seems to suggest that we are missing something about setting up hyperv infra. I wonder if its possible to inspect the content of the page 2c04e000 - maybe there is any hint... I did browse https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercalls/overview a bit, but I do not think there is something wrong about that one; however, it may be 21:57:57 worth walking through Implementation Recommendations (https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/feature-discovery) ... sorry if its too obvious thing to suggest.. 21:59:35 yeah, we note all of those, though we don't use hypercalls for all of those 22:00:38 (really, when it was originally ported by delphix, it probably should have been its own platform like x86xpv because it wants to use custom implementations for address space switches, tlb flushes, apic EOI, etc (though it can still emulate like you're on normal hardware) 22:03:22 trying to add a bunch of 'if (hyperv) { do_hypercall() } else { do_hw_thing() }' would get rather ugly 22:18:54 have you tested linux or freebsd vm on windows 2025? both of those are claimed to be supported, maybe logs will provide hits there? 22:23:20 btw, what address that vm gets for framebuffer? framebuffer get from loader ok prompt. 22:23:57 f8000000 22:25:02 * On Gen2 VMs, Hyper-V provides mmio space for framebuffer. 22:25:57 freebsd boots right up 22:28:56 i believe that's all driven from the ACPI info 22:29:26 there isn't a PCI-LPC bridge (often there's no PCI at all) 22:30:21 but if ACPI enumerates the vmbus, we also create an isa device off the root nexus which acts as the parent to the fb (and serial ports) 22:30:41 hm, that too... 22:30:58 (this all works in 2019 or older) 22:31:25 I am browsing fbsd sys/dev/hyperv/vmbus atm:D 22:31:41 it's not the easiest code to follow 22:31:47 it's like taskq-ception :) 22:33:31 hyperv.c is where the hypercall stuff gets setup 22:33:42 yep. 22:33:44 then vmbus issues hypercalls to pass messages to hyperv 22:34:02 and then messages get written back and interrupts issues 22:37:16 https://github.com/omniosorg/illumos-omnios/tree/master/usr/src/uts/intel/io/hyperv/vmbus is our equivalent code 22:44:32 i do feel like we could improve the vmbus nexus driver further, but since it's completely undocumented (apparently even inside of microsoft), it's a lot of work to try to go backwards 22:44:46 (not that any of that I don't think is relevant to the clear_boot_mappings() hang)