Jeroen Janssen wrote:
> > 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.
>
> I assume we would have some kind of "register callback" functions and
> the Channel ID will be used to call the correct "device" function?
>
> it might be "better" to specify as less as possible in the packet
> (enough to identify the channel id, since for different types of
> devices, each may have their own requirements of buffers, etc)... it's
> probably better to let the "device callback" handle this kind of
> information.
Yep we'll have a register callback function. Channel ID could
be moved into the data section, where it would be part of the
callback's definition, as you mention.
> > The question is what kind of addresses to use. If the guest could specify
> > physical addresses, that would simplify things.
>
> then it's probably the best way to implement some testing code.
>
> > 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.
>
> is there a specific advantage of using the linear address?
Well, if the buffer consists of a large number of pages, it
may be hard for the driver to aquire such a contiguous run of physical
pages from the guest kernel.
We should think in terms of how to handle this now, and
architect things right, from the beginning.
The VM monitor has the ability to decode a linear address (and size)
into a series of guest physical pages. But we don't want to do
that for each interaction between the guest driver and the
'outside world'.
I think that as part of the interface, each special
driver sends init sequences to the special IO port.
One would be "I'm here and going live". Another
would be "Here's a list of the physical pages which comprise
my data buffer #X". Another "I'm shutting down".
This would be very dynamic. For example, when booting via the
BIOS the VGA emulation would be used. When we get a "going live"
sequence, some special video acceleration takes over. When
"shutting down", back to the VGA emulation.
-Kevin
