Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device

[Gleb Natapov]

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.

> > 
> >>> 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!

--
                        Gleb.