On 19.07.2010, at 11:10, Gleb Natapov wrote: > 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.
I don't think I understand what you mean? > >>> 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. The virtio-blk model uses the whole pxe framework. For our in-tree option roms we're trying to be simple. And I'd like to keep it that way. I really don't want to add PCI enumeration and BAR setup to that code. Alex
