On 19.07.2010, at 11:19, Gleb Natapov wrote: > On Mon, Jul 19, 2010 at 11:13:38AM +0200, Alexander Graf wrote: >> >> 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? >> > Vcpu executes "in %ax". Next instruction is executed 6 seconds later. > All timers that should have been processed during this time fire at the > same moment triggering all kind of timeouts. Think about watchdog that > should be written into every two seconds otherwise it does reset.
That's a hypervisor implementation detail! If we want to go synchronously, we do. If something breaks, we don't. Doing it synchronously simpllifies things a lot. And we're talking about a device that's only used before the OS kicks in. There's no use in pretending we're running a watchdog there. > >>> >>>>> 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. >> > The virtio-blk is entirely in seabios and does not use pxe at all! So it uses even more framework :). The linuxboot stuff is completely separate in its very own option rom. Alex
