On Wed, 6 Oct 1999, Kevin P. Lawton wrote:
> Sounds interesting. Would the guest OS see and be able to drive
> the parallel hardware as normal using ppdev? I'm not familiar with
> it.
The idea is that we'd trap things like outb's at 0x378 (or whichever base
address we choose) and turn them into ioctls on /dev/parport0. If we have
a virtual DMA controller too we can write blocks of data to /dev/parport0
and save time (if the guest OS driver uses DMA).
Similarly for FIFOs: lots of parallel port chips have a 16-byte FIFO. We
can say that our virtual parallel port does too, and then we at least can
write in blocks of 16 bytes.
The slow bit, I think, is switching from 'just trapped an I/O insn' to
a mode in which 'perform ioctl on dev' is possible. Thinking about it
some more though, we'd be in the monitor once the I/O insn is trapped
wouldn't we? In that case we could use parport directly
(parport_write_data etc.).
> Does VMware directly use the parallel port IO ports after the probing?
Yes. I think it blocks some out and pretends that the underlying hardware
is quite simple, to save the guest OS thinking that it can set up a DMA
transfer or anything. That way their code can work with most all of the
hardware that's out there.
Tim.
*/
