Ketil Froyn wrote:
> > Anyways, what kind of card is this you're talking about?
>
> It's a RealMagic Hollywood+ MPG (DVD) card. Sigmadesigns are refusing to
> release specs for linux, so I am being forced to reboot to view an mpeg on
> my television. But I'm sure there is lots of other hardware where
> something like this could come in handy, like for example winmodems and
> winprinters, and in general any new hardware that doesn't have support
> under linux yet.
My guess is that after we get Windows running in FreeMWare,
there will be a lot of people who want to use pass-through
devices, and thus a big push behind implementing it.
I plan to dive in and learn more about PnP issues when
the time comes, myself. My guess is that we'll have
to offer PnP in our guest environment, make the host
system nail down the settings, and command the guest
to use those settings. Anyone who understands this
stuff, please chime in. It would be useful to get
a thread going on this. I've received quite a few
emails from people requesting this kind of thing.
Those issues aside, maybe virtualizing a
pass-through device with DMA might go something like:
- Guest code sets up DMA controller for transfer. This gets
redirected to our emulation of a DMA controller, which in turn
recognizes that the operation is meant for the pass-through logic,
and commands the real DMA controller appropriately, using host services.
Ideally the memory address we use in the real DMA controller would point
into guest memory. That would mean those pages of guest memory would have
to be DMA capable, or we will have to use private DMA capable pages,
and then copy the data into guest memory after the transfer is done.
For performance, letting the DMA write directly into buffers in
the guest memory would be ideal. Since the pages we allocate for
guest physical memory are not necessarily DMA capable, we
could allocate a handful of DMA capable pages before hand,
then use an adaptive technique to substitute non-DMA-capable
pages for ones that are. The first use, we'd have to copy
the data. Likely after that, guest buffers are reused, so
we would not have to do this again.
- Guest code communicates through IO ports to set up the card
for a DMA request. Our VM either let's the IO accesses
occur directly via the IO port permissions map in the TSS,
or we redirect them.
- The DMA transfer occurs.
- We have to propogate any IRQs originating from the pass-through
device to the emulation of the PICs. We must take care of business
on the host side, letting our host interrupt handler tell the host OS
that we have handled the interrupt, then reflect it back to the
PIC emulation in the VM monitor.
Again, settings such as DMA and IRQ must be coordinated between the
host/guest, such that there are no conflicts. It's not so much necessary
that the values be identical, but more to the point that we don't
let the guest drive the hardware to use values that will screw up
the host.
We'd also have to make sure that the DMA buffers didn't access
virtualized structures that we are trying to protect, like virtualized
code, system tables etc.
-Kevin
