qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device
Date: Mon, 19 Jul 2010 10:54:43 +0200

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?

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


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]