On Mon, Jul 19, 2010 at 11:02:54AM +0200, Alexander Graf wrote:
>
> On 19.07.2010, at 11:00, Gleb Natapov wrote:
>
> > On Mon, Jul 19, 2010 at 10:54:43AM +0200, Alexander Graf wrote:
> >>
> >> On 19.07.2010, at 10:48, Gleb Natapov wrote:
> >>
> >>>
> >>>> Were there DMA capable devices back in ISA times? There must be. If so,
> >>>> we can just take a look at what they do and do it similarly. Bus
> >>>> mastering was a new thing for PCI, right?
> >>>>
> >>> I think IDE can be considered DMA capable ISA device, no? At least
> >>> it works by writing to PIO ports and getting result into memory, but
> >>> with interrupts and status bits and everything that real device should
> >>> have. On board DMA engine is also ISA device.
> >>
> >> We could define our device to be polling. So all we need is a status bit
> >> that the guest sets when it starts the DMA and the device unsets when the
> >> DMA is done. In our case that should be immediate, because the PIO invokes
> >> the full code paths, but it would look more like a real device, no?
> >>
> > This is better, but it shouldn't be synchronous. Kernel and initrd are
> > on disk so why not setup aio and read them from io thread allowing vcpu
> > thread immediately return to guest mode to process interrupts.
>
> That would work with the above described device model. If we're going
> synchronous or asynchronous would become an implementation detail.
>
If vcpu thread will sleep for too much time without processing events we can
see strange timeouts in a guest.
> > Or why
> > not use virtio-serial while we are at it? After all virtio-serial is
> > there to allow host and guest communication.
>
> Because virtio-serial needs us to set up the full virtio-pci stack. That's
> too much to mess with in an option rom IMHO.
>
We already do it for virtio-blk. Read only support is very small in
LOC there. Don't know about virtio-serial protocol.
--
Gleb.
