IRC channel logs

<SlySven>May I offer some cheering from the sidelines damo22 - only barely following what you are doing but even I can see it will be essential to get SMP working - and as my current real hardware Hurd box is a dual-core one, each with 64-bits! 8-) I look forward to seeing developments.

***Server sets mode: +nt

<damo22>:)

<damo22>one thing that im not sure about is the mapping of APIC pins to PIRQx, apparently you have to parse the DSDT AML to get the actual mappings of apic pins to pci irqs. Or does it not matter? can you just run it with a one to one mapping in all cases?

<damo22>that is, GSI 16-23 are PIRQA to PIRQH but may be in a different order

<damo22>ive already fixed the ISA irq overrides for APIC, they are done

<damo22>id like to avoid putting a AML parser in gnumach

<SlySven>?

<SlySven>Sorry, but that is outside of my expertise - when I first got into PCs you often configured IRQs by putting jumpers onto pairs of pins on expansion cards (or the motherboard)!

<damo22>hehe

<damo22>unfortunately, we need the AML ACPI parser to know which device is mapped to which PIRQ

<jrtc27>ACPI makes me so sad, such an overengineered spec that is built on the hardware injecting arbitrary binary blobs into your OS

<damo22>hmm, just talking to coreboot devs, there is a scratch pad register in every pci device config space

<damo22>we could do a dance where ACPICA can run in userspace and communicate the apic pin back to the scratch register per device and the kernel can pick it up and reconfigure APIC

<SlySven>But does anything use it? >8-]

<damo22>no

<SlySven>*evil cackle* do you have some plans for them then?

<damo22>well, we could get gnumach to init the scratch reg to 0 and then wait for the acpi server to decode the apic pin mappings back to the scratch reg, and then the kernel will know which device uses which apic pin

<SlySven>BTW does anyone know if the output given from "man sysinfo" is just wishful thinking at this time?

<jrtc27>I assume this is for INTx not MSI(-X)?

<damo22>PIRQx

<SlySven>There *isn't* a pin *0* is there?

<damo22>i think there is

<jrtc27>ok so the other end of INTx

<damo22>yes

<damo22>or we could jump straight to MSI interrupts

<damo22>and skip PIRQx

<damo22>not sure how the devices map to those though

<damo22>actually there would be no waiting involved, just let gnumach assume a 1:1 mapping if the scratch reg is 0, or if its populated, use that instead

<damo22>then all the ACPICA crap can go in userspace and not taint the kernel

<damo22>and the request for irq can check the scratch reg every time userspace asks for a new irq

<damo22>ie the overrides happen in real time

<SlySven>Well, who'd have thought it - I've managed to get the project I code for: "Mudlet" https://github.com/Mudlet to compile and run on the GNU/Hurd with only one bit of platform specific hackery...

<SlySven>Dammit, that should of been https://github.com/Mudlet/Mudlet .

<damo22>most of debian is ported to hurd, im not that surprised

<damo22>im excited because it boots even quicker because it doesnt probe irqs

<damo22>hmm maybe the arbiter can do the remapping, then gnumach doesnt care

<damo22>is device/intr in gnumach? where is the RPC defined for interrupts i forgot

<damo22>we made it a kernel RPC right?

<damo22>maybe the kernel RPC implementation can make an RPC to pci-arbiter to request the apic pin of a device?

<damo22>then it would still work if we used IOMMU in the future

<damo22>hmm but usually when you request an IRQ you need the arbiter as well to get access to PCI, so we can ensure we ask for the right IRQ by returning the real APIC pin back from an RPC from the arbiter

<damo22>we just need a new RPC in pci-arbiter called S_get_irq_number(pci_device_t dev, int *irq)

<damo22>and that can call the ACPI server mostly, until we get IOMMU support

<damo22>and then the kernel request for irq can use the real pins

<damo22>S_pci_conf_get_irq(protid *master, int *irq)

<damo22>since you cant just read it out of the config file, its not correct

<damo22>S_acpi_dsdt_get_pirq(protid *master, int bus, int dev, int func, int *pirq)

<youpi>damo22: does the kernel itself really need to request the mapping? if it's only about pci devices, users of the device_intr_register RPC can just first ask pci-arbiter itself what irq they should request from device_intr_register

<youpi>so the kernel just obeys and doesn't care about parsing

<damo22>yes you are correct, i suggested that last in my ramblings

<damo22>we just need a new RPC in pci that looks up the actual IRQ

<damo22>probably by asking ACPI

<damo22>somehow the linux drivers in mach are interfering with the keyboard IRQ i cant seem to unmask irq 1

<youpi>iirc the linux glue is just calling the mach irq management

<damo22>i called unmask_irq(1) in kdinit()

<damo22>but the irq is still masked after bootup

<damo22>and it triggers, and then gets stuck on

<damo22>actually i dont know, there is some pending interrupt flag in qemu that tells you about interrupts

<damo22>info pic says IRR =1

<damo22>regarding the ioapic

<damo22>i feel like this is so close, everything works except the keyboatrd

<damo22>i added this in reserve_mach_irqs:

<damo22>+ /* Timer and keyboard */

<damo22>+ if (i == 0 || i == 1)

<damo22>+ irq_action[i] = (struct linux_action *) &reserved_mach;

<damo22>(19:02:25) youpi: iirc the linux glue is just calling the mach irq management

<damo22>Yes but the kdintr is a mach device interrupt, not a linux one

<damo22>handler*

<damo22>i thought if i unmask_irq(1) it will stay unmasked forever, so long as linux/ code does not mess with it

<youpi>note that we'll get rid of the linux glue when we have rumpdisk working

<damo22>:)

<damo22>why does commenting out linux_init() cause some kind of array overrun?

<damo22>how do i compile gnumach with no LINUX_DEV defined?

<youpi>grep LINUX_DEV gives linux/configfrag.ac: AC_DEFINE([LINUX_DEV], [1], [Linux device drivers.])

<damo22>haha i'll try 0

<youpi>you'd probably need to fix some stuff since basically nobody has been doing it for decades

<youpi>apparently have_linux_code=yes is getting set as soon as a driver is enabled

<youpi>we'd probably want an option to disable all drivers altogether

<youpi>(the linux ones I mean of course)

<damo22>yes

<damo22>maybe that can be my next real patch

<damo22>heh only one missing symbol

<damo22>install_user_intr_handler

<damo22>i suppose that stuff from linux/dev/...irq.c should be moved out of linux/

<damo22>as it was not part of linux

<damo22>or a version of it to be written that does not rely on the linux/ tree

<youpi>rather a version that doesn't rely on the linux irq handling yes

<damo22>its weird because the actual handler does not get passed in as a function

<damo22>shouldnt there be a function pointer that is the actual handler?

<youpi>for user handlers it's just a port, in user_intr_t

<damo22>ahh

<damo22>insert_intr_entry already inserts an interrupt

<damo22>do we need install_user_intr_handler?

<damo22>or is that just for linux

<damo22>s/inserts an interrupt/installs a port

<youpi>we do need it for userspace intr ha,ndlers

<damo22>in device/ds_routines.c , ds_device_intr_register() already seems to install a port using insert_intr_entry

<youpi>yes but we need to somehow register it to some interrupt handler

<youpi>currently it's just delegating it to the linux irq handler

<damo22>so we need to accept a function pointer to be the handler?

<youpi>?

<youpi>we need to extend the irq handling infrastructure to somehow take the user port and call the user intr signaling, like the current linux irq handler does

<damo22>yes ive read that code, it needs to call ivect[irq] = some function pointer

<youpi>? no, the user intr handling is further away

<youpi> if (!deliver_user_intr(&irqtab, irq, action->user_intr))

<youpi>that's the basic thing tha needs to be called

<damo22>ahh

<damo22>Thread 1 received signal SIGQUIT, Quit.

<damo22>trap_from_kernel () at ../i386/i386/locore.S:559

<damo22>what is an early function to breakpoint on in the kernel?

<damo22>im using gdb target remote :1234

<damo22>i got Page fault traps save cr2

<damo22>pretty sure i hit t_page_fault

<damo22>ETIRED

IRC channel logs

2021-03-23.log