Re: SCSI / PCI

> The biggest problem with this is exactly as Jeremy said. There is not a
> convinent way to open 'all of IO space' and I'm not sure you would even
> want to do this. I think the best solution here would be a signal handler
> which would allow the program to handle unallowed accesses to IO or MEMORY
> space. This would not only allow this to work (i.e. the signal handler
> would open up the IO register when the BIOS32 code tried to access it, and
> then it would let it continue to run) but this would also allow in program
> page fault handlers and such later.

I ran with IOPL=3 for a while. When I went to using per-process IO
bitmaps, I changed the PCI configuration space accesses to use an IPC
(essentially to a PCI config space arbiter, which could enforce access
controls). The IPC was not a performance problem, as PCI configuration
registers are only read during the driver initialization phase.

Allowing access to the low-level registers or BIOS32 is problematic
as both are (by their nature) non-reentrant, so only one process can
use them at a time (technically that is only true for one of the config
mechanisms). There is also the security issue: if a process
can "disable" arbitrary PCI devices, you might as well just give it
full IO permissions. Having a trusted process handle all accesses to
PCI configuration space isn't so bad (IMHO). BTW, the PCI BIOS32
doesn't need all of IO space, but it does need IOPL3 to disable
interrupts, so the issue is moot.

Anyway, this has gone on long enough. If you want code to access
PCI config space directly, look at the FreeBSD code; if you want
to try BIOS32, I was able to adapt the Linux 2.0.x code by mapping
128k (and not worrying about the BASE/BOUNDS) of BIOS and adjusting
the search to use the virtual instead of physical addresses. (I
now use the FreeBSD code to avoid dealing with it.)

Kevin
Received on Sat Jun 27 15:49:50 1998