Colin Davidson wrote,
> Hi Everyone,
> There are some general issues and trade-offs around peripheral handling that
> I thought worth thinking about in general and bearing in mind while we
> discuss particular peripheral situations.
> There are at least four approaches to supporting peripherals in Guest OSes:
> 1) Segragate the machine. Have the Guest OS use one set of hardware and the
> Host OS another. This is very little work, most of which is required
> regardless of the approach actually taken, but requires extra hardware (LAN
> card, display adapter, mouse, keyboard, disk controller and hard disk ... At
> some point, you ask yourself why you don't just use 2 machines. In some
> circumstances, though, it will give maximum performance for minimum effort
> and can be really worthwhile if you need either (graphics comes to mind
> here).
> 2) Emulate a known piece of hardware - Ne2000, 3dfx voodoo3, etc, etc. Use
> the standard Guest drivers but punt their implementation to a host device.
> This allows the support to be written once, but kept up-to-date with the
> latest driver from the hardware supplier - for as long as that supplier
> supports the device in question. It relies on the hardware spec. being well
> enough known to emulate and assumes that the hardware/driver interface is
> simpler than the OS/driver interface. As it is at a lower level than the
> OS/driver interface, it will almost inevitably be less efficient than a
> higher-level emulation.
It's maybe incorrect and weird but for the same reasons I like the
emulation of real hardware. It makes another strong point - when
another new OS which supports this particular video/network adapter is
out, there's no need to write new guests drivers. But, disadvantages
are major as well :-(( This video hardware has to be limited and less
advanced than the most feature-rich ones to run efficiently on every
range of host hardware (I think you're right that voodoo family is a
good target), which means that emulated hardware will be outdated
(though much better than VGA anyway).
> 3) Emulate an virtual piece of hardware, designed to be easy and efficient
> to emulate. This hardware does not have to have any real existance. The
> Guest driver captures the OS requests and passes them over to a
> corresponding handler on the Host. This will be about as efficient as
> emulation can be, but may need frequent updates in rapidly changing areas
> (DirectX, e.g.). It assumes access to Guest driver writing capabilities
> (Windows DDKs, e.g.) and suffers from a potential problem of only being
> partially open-source, as the driver may have to live "in" a proprietory
> environment. Nonetheless, it may be well worth pursuing in cases where the
> driver needs to be efficient but dual hardware is prohibitive.
It's a good approach as well. Can't choose from 2/3.. I hope Kewin
will decide himself what's better. I bet that most of kernel hackers
will prefer such abstraction.
> 4) Use to same hardware in both OSes. This is really only possible for
> stateless, synchronous peripherals, such as keyboards and mice, perhaps
> (also potentially devices such as printers, which can report a "busy"
> condition while being used by the other OS. Stateful peripherals, such as
> display adapters, and asynchronous peripherals, such as LAN cards and
> Modems, are a poor choice for hardware sharing. In most cases, this is a BAD
> IDEA. Even where hardware can be share, some mechanism is required to
> enforce sharing, so that only one OS at a time will actually access the
> hardware.
Display adapters should be OK for hardware sharing when they are in
full-screen, exclusive mode. However it turns to be video
hardware-dependent, so maybe it was not so good idea of mine. Except
for VGA part which is widely-common subset of (almost) every SVGA out
there. Full-screen VGA exclusive access should be implemented easily,
- with only 256K of RAM, simple, well-documented architecture. And
it's not useless, at least for some old apps, also for rare OS'es
which wouldn't have a chance to have special guest drivers developed.
Using SDL and mapping framebuffer to guest is a good idea as well.
With direct framebuffer access VESA VBE can be easily implemented. I
hope that full-screen VGA will be implemented at least.. because it's
only way to get decent non-accelerated VGA performance, especially in
latched modes (to get the accelerated SVGA's performance another
choices you've mentioned can be used).
> Note that in many cases, these option will not be exclusive and the actual
> best solution will depend on the situation at hand - what the user can
> afford, what applications are running, personal ideology and a host of other
> factors. Where possible the implementation of a solution should not prohibit
> the implementation of an alternative. This really is a case of the more the
> merrier, so long as we get *something* working in a reasonable timeframe.
Very interesting ideas! Can't add much to your thoughts.
Uhus
