IRC channel logs
2026-02-10.log
back to list of logs
<rrq>"not very good" is a choice, but yes, one needs to adapt to reality <youpi>yes, sure, but that's really still very far <youpi>we really have more urgent matters <damo22>nexussfan: some countries like Australia dont really have much IPv6 <damo22>i havent taken the time to learn it yet either <damo22>most of australia doesnt have internet access anyway, nobody lives in the middle <damo22>everyone else has fibre to the street and copper wire from the street to their house with a DSL modem to connect the last 10 metres <rrq>well, individual people do live well spread out across the continent <rrq>btw I get a /48 block from AussieBB but I'm still weary about the firewalling <damo22>i cant justify paying $80/month on wired internet when i can get LTE for $35/month <damo22>the only thing i miss is the public static ip <damo22>youpi: there is no mechanism to query a vcpu for its vcpu_id in xen smp. The only way is to store it in a dedicated section at the top of the initial stack that each vcpu launches with. But im unsure how to get back to the original stack every time i want to query the cpu id <damo22>basically i am struggling to implement cpu_number() <damo22>eg, if i store the initial stacks as an array i still need to know which vcpu is executing to be able to look up that array <damo22>the xen developers tell me i am free to put the vcpu_id anywhere in the kernel so its my problem <damo22>if mach-xen never switches stacks within kernel, that would mean i could just look up the top of the stack to find the vcpu_id <damo22>ie, relative to the initial stack it runs with <damo22>not sure if that is a viable option <youpi>rrq: rdtscp/cpuid provides information about the real cpu id, what we want is the vcpu id <youpi>damo22: not switching kernel stack would be a mess <youpi>damo22: with fs/gs access, the current vcpuid can be stored in current_thread()->cpuid <damo22>youpi: with fs/gs i can use MY(VCPU_ID) that isnt a problem but what about when i dont have gs access <damo22>there are a few places in the code where i just dont know what to do <damo22>SWAPGS_ENTRY_IF_NEEDED_R12 and SET_KERNEL_SEGMENTS could be squashed together then we would always guarantee GS is available? <damo22>but its different depending on user32 <youpi>damo22: for interrupts/syscall, I don't remember how that works on xen, it doesn't provide the vcpu id on entry? <youpi>when interrupting from userland, we really need to know the information somehow, we cannot just make it up <youpi>ah, but we could put it somewhere on the kernel stack of the thread, and update it on thread switch <youpi>I'm still surprised we don't have some xen helper for that <damo22>i removed all instances of CPU_NUMBER_NO_* <youpi>I was thinking we should be able to just use %gs after swapgs yes <damo22>if that is fine, i can implement xen smp like that too <youpi>yes, and that's less costly than the _NO variants :) <youpi>we will be pushing segments on the stack even when we are already on the intstack, but that's fine enough <damo22>actually we failed an extra test <damo22>timer calibration...{cpu0} ../kern/mach_clock.c:479: reset_timeout: Assertion `!queue_empty(spoke)' failed.panic {cpu0} ../kern/debug.c:103: Debugger: Debugger invoked, but there isn't one!FAIL tests/test-hello (exit status: 12) <janneke>so...the 32-bit (intel) hurd can be installed and run on bare iron, possibly even as a daily driver when you use debian... <janneke>...but for the 64-bit (intel) hurd, we need to choose qemu --machine q35 or else there's some startup or memory restriction? <janneke>any ideas what is missing to run the 64-bit hurd on bare iron (other maybe than drivers, of course?) <azert>janneke: it just depends on your hardware <azert>for the most part, i386 and x64 has the same drivers. <azert>we had people installing x64 on bare iron <azert>only issue is that x64 is generally newer. As such less devices are supported <damo22>janneke: x86_64 hurd + SMP is not ready <damo22>but the uniprocessor variant should be usable <janneke>damo22: okay, but SMP is a separate issue i think? <janneke>ACTION is not trying to be impatient, just writing a blog post about bringing x86_64-gnu to guix <rrq>janneke: I'm running qemu on "-m 2G -M pc,accel=kvm -cpu host -smp 1" which is alias of pc-i440fx-10.0 <janneke>azeem: a, do you have a link / more information on that? <rrq>my cpu is "13th Gen Intel(R) Core(TM) i5-13420H" <damo22>rrq that is interesting, the -smp 1 seems critical to force the APIC to be detected <rrq>right; haven't thought of it other than it didn't work with >1 :) <damo22>it could potentially work with -smp N if you just run the non-smp gnumach but N-1 cores would be sitting idle <azert>if you look at the messages that month, Kelly fixed pci hw detection that month to achieve that <damo22>yeah post IRQ "issues" we resolved, a lot more hw should now be working <azeem>ah you meant azert who had just left <damo22>does qemu have a xen mode so i can test gnumach-xen? <janneke>azeem: yeah sorry, i meant azert "<azert> we had people installing x64 on bare iron" <janneke>but yeah, amazing; i wasn't aware of 64bit successfully running on bare metal <Pellescours>I got some git clone commainds that failed recently, so I took the git repository and ran tests. And I see a test failing for a strange reason (t0052 step 8), the begining of the file where it store the result (named `actual`) is not complete, the beginning of the file is missing. <Pellescours>By investiguating a bit I see that it’s caused by 2 steps before, If I comment the step "slow response", the the step "mutliple" works (file has effectivelly all the lines). If the step "slow response" run, then the 20th first lines of the step "multiple" does not appear in the file