Hi,
ucosty wrote:edit: And I suspect Brendan has no clue what the guy is on about either.
You're mostly right - the original questions in this topic make no sense at all, but I was sent an email requesting an answer and obliged in the best way I could.
However, I do have some background knowledge about what Sawdust is trying to do. The background knowledge is that Sawdust is trying to implement a type of OS that runs on one CPU while Linux runs on another, with a type of device driver built into Linux so that his OS and Linux can communicate. For some reason this is hardware specific code (not general purpose code that could work on other CPUs/motherboards) and needs to use LinuxBIOS, which makes it very difficult to debug and test. I have no idea what the reason is for it or what it'd be used for (other than he says he's hoping to get some sort of grant for it if/when it works).
I assume he's trying to figure out how to get his OS and Linux to communicate, needs some sort of buffer that's shared between the Linux driver and his OS for this communication, and is allocating some RAM for this buffer from within Linux and trying to find a way to tell his OS the address of this buffer.
However, I have no idea what this has to do with any PCI-X card, or why the Linux driver for his OS needs any physical device (except RAM and CPU/s). I'm guessing he's misusing PCI configuration space as a way to tell his OS the address of the communication buffer, without considering how his OS can reliably access PCI configuration space without causing re-entrancy problems (without some sort of lock, both OSs could be trying to use the PCI configuration space "address" and "data" I/O ports at the same time and stuffing each other's PCI configuration space accesses up).
I think the general problem may be that Linux assumes it has complete control of the computer and therefore his OS can't have control over anything, except for things that can be hidden from Linux by hacking the firmware (e.g. make LinuxBIOS generate MP specification tables and/or ACPI tables that don't include one of the CPUs, and modify the memory map passed from LinuxBIOS to Linux so that Linux doesn't know about some RAM).
In general (based on some assumptions and guessing what the real questions are) he should using a fixed address in RAM to tell his OS where this buffer is.
If this isn't possible for some reason then using IPIs alone can work (by sending IPIs from the Linux driver to his OS): with 2 interrupt vectors (e.g. interrupt 0x80 and interrupt 0x81) you can send one bit per IPI, and would need to send a sequence of 32 IPIs for 32-bits. If the address of the communication buffer is aligned, then you wouldn't need to send the full 32-bits (e.g. only send 20 bits if it's aligned on a page boundary because you know the lowest 12 bits are zero).
With 32 interrupt vectors you can send 5 bits per IPI (e.g. interrupt 0x80 = 00000b, interrupt 0x81 = 00001b, interrupt 0x82 = 00010b, ..., interrupt 0x9E = 11110b, interrupt 0x9F = 11111b) and you'd only need to send 4 IPIs from Linux to his OS to tell his OS the 20 most significant bits of a page aligned communication buffer.
Cheers,
Brendan