--- "Kevin P. Lawton" wrote: > 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 linuxBut I'm sure there is lots >>of otherhardware where > > something like this could come in handy, like for > example winmodems and > > winprinters....... > 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. Well....., many of the system devices and friends (com ports, lpt ports, usb, ps2, IEEE-1394, IrDA, etc.), and for that matter many "PnP" devices prefer to live at a predesignated real hardware address and therefore should not be too hard to re-route. Also, it should not be too hard to figure out that some sort of hardware that linux can't deal with is trying to read/write from/to real memory, IRQ, and DMA resouces at specific addresses.......after all even MS-DOS can do that. > > 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 I like your sample DMA psuedo-code....... it looks good to me based on what I know. Drew Northup, N1XIM __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
