A couple quick thoughts on this special guest OS driver
interface...
There will be a need for such drivers for multiple devices,
if we want to get the most out of plex86. Video, disk,
network card, etc... Thus we should define a simple and generic
interface from the guest to the host.
For efficiency and simplicity, it is most beneficial if
the guest OS driver uses a memory buffer which is locked
down in guest memory, so we don't have to worry about
page faults. I'm thinking the driver writes a packet
of information, to this memory buffer, and passes some information
regarding the location of that packet via IO ports. This tells
the VM where to find the packet, and it can then
redirect this info to the corresponding host user
code which handles the data.
We might have a packet like this:
- Packet physical address
- Magic Number
- Packet length (not including header)
- Channel ID (in case there are multiple data channels for a device)
- Return buffer address (if needed)
- Return buffer size (if needed)
- Data (driver specific)
The guest driver would tell the VM about this packet by a single
dword write, specifying the address of the packet itself. The
magic number in the packet would double check this is meant for
our interface.
The question is what kind of addresses to use. If the guest
could specify physical addresses, that would simplify things.
That would mean for packets of over one page in size, the
data would have to be in contiguous physical memory. If we
specify linear addresses, then each host user space driver
component will need to call a function to do the translation
from linear --> physical memory, so that it can access the
guest's phy memory.
-Kevin
