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

[Gleb Natapov <gleb@redhat.com>]

On Mon, Jul 19, 2010 at 10:54:43AM +0200, Alexander Graf wrote:
> 
> On 19.07.2010, at 10:48, Gleb Natapov wrote:
> 
> > On Mon, Jul 19, 2010 at 10:41:48AM +0200, Alexander Graf wrote:
> >> 
> >> On 19.07.2010, at 10:30, Gleb Natapov wrote:
> >> 
> >>> On Mon, Jul 19, 2010 at 10:24:46AM +0200, Alexander Graf wrote:
> >>>> 
> >>>> On 19.07.2010, at 10:19, Gleb Natapov wrote:
> >>>> 
> >>>> Yes and no. It sounds nice at first, but doesn't quite fit. There are two issues:
> >>>> 
> >>>> 1) We need a new PCI ID
> >>> We have our range. We can allocate from there.
> >>> 
> >>>> 2) There can be a lot of initrd binaries with multiboot. We only have a limited amount of BARs
> >>>> 
> >>> Is it supported now with fw_cfg interface? My main concern with this
> >>> approach is huge BAR size that may take a lot of space from PCI MMIO range
> >>> if guest OS decide to configure it.
> >> 
> >> Oh, right. I think I combined all the modules into the INITRD blob. Yeah, that would work. Is coalesced MMIO more efficient than coalesced PIO? Or do we have to do some RAM mapping for those special BAR regions?
> >> 
> > I think we will have to do RAM mapping. Otherwise it may be slow to.
> > Coalesced MMIO is for write not read IIRC.
> 
> Oh, right. Makes sense.
> 
> > 
> >> 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. Or why
not use virtio-serial while we are at it? After all virtio-serial is
there to allow host and guest communication.

> outb(PORT_DMA_CTL, FWCFG_DMA_ENABLE);
> while (inb(PORT_DMA_CTL) & FWCFG_DMA_ENABLE) {
>     /* DMA going on */
> }
> /* DMA done */
> 
> 
> Alex

--
			Gleb.