Pineau C�dric wrote:
>
> Aren't there problems in letting the guest OS driving somes IO by itself ?
> Most of drivers have to deal with timings when speaking to peripherals.
> What happens then if we or the host OS interrupt this drivers for others
> tasks ?
True. We'll have to work out a way of defining what resources
a particular direct device requires (IRQ, DMA, PnP, IO ports, IO mem, ...)
and determine whether we can make it cooperate with the host.
IO ports aren't much problem. For the IRQ, we might better allocate
that IRQ in the host, and set up a handler. IRQs that occur when
in host space could be handled by a simple int handler that
sets a flag and then uses the kernel services to notify the
PIC. Next time slice we could drill the guest with an interrupt.
Maybe while in guest space, we could reflect the int back to the host,
have a small host handler essentially do as above. If there's
nothing else to do then the guest could continue on after
effectively receiving the interrupt.
Mostly, I'm thinking in terms of a multiple processor machine,
where we don't want to play with notifying the (L)APIC ourselves.
For IO memory mapped areas, seems like we could just map there
physical addresses into the guest's linear space. Have to
make sure the chipset on the host side knows whether
this is an uncacheable memory region.
PnP issues should get interesting.
Anyways, I envision having a directive in the .rc file, one for
each special direct IO device. You specify the resources required
for your board, and/or how to configure it. I'm not sure this
is going to work for all hardware, but maybe we can get some
boards to work, like a video card.
-Kevin
