>
> For efficiency's sake, we'll need some custom drivers for each
> major guest OS. It's a lot faster to have say Windows talking
> to a native Windows driver which could blast data back/forth
> between the driver and the host OS, then it would to have
> it talking to a standard emulated device via IO.
>
> Key drivers would likely include video, hard disk, and
> networking. The actual interface we can make up, so there's
> a lot of freedom. The more efficient the better. For moving
> data, I think essentially you get a packet of data ready in
> paged-in memory, then notify the VM/emulator via a couple
> IO port accesses where the data is. The VM environment
> moves the data around and performs an action on it, without
> the extra overhead involved in emulating hardware.
>
> If you'd like to help on this front, please let me know.
> You can use bochs to develop the driver since it runs Windows
> already. Someone is playing with a special Windows video
> driver. You might want to either coordinate on that, or
> perhaps make a disk/network driver.
sounds good. i'd rather stick to disk/network drivers - more comfortable
there.
>
> It's a pretty modular task. I can help by working with you
> to create a simple interface in the bochs IO device models.
> You can code the driver itself using the specs.
>
ok.
> It should be fairly similar to coding a normal driver, except
> you don't worry about IRQs, DMA and all that. There are some
> cool possibilities for the video driver, if someone was enthusiastic.
> Seems like there is potential to pass rendering directives via
> such an interface to the VM, and have the host GUI do the rendering.
> Comments?
>
>
> -Kevin
>
