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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/19/2010 11:11 AM, Gleb Natapov wrote:
> On Mon, Jul 19, 2010 at 10:54:03AM -0500, Anthony Liguori wrote:
>    
>> On 07/19/2010 09:53 AM, Gleb Natapov wrote:
>>      
>>> On Mon, Jul 19, 2010 at 09:45:58AM -0500, Anthony Liguori wrote:
>>>        
>>>> On 07/19/2010 02:33 AM, Gleb Natapov wrote:
>>>>          
>>>>> On Mon, Jul 19, 2010 at 08:28:02AM +0100, Richard W.M. Jones wrote:
>>>>>            
>>>>>> On Mon, Jul 19, 2010 at 09:23:56AM +0300, Gleb Natapov wrote:
>>>>>>              
>>>>>>> That what I am warring about too. If we are adding device we have to be
>>>>>>> sure such device can actually exist on real hw too otherwise we may have
>>>>>>> problems later.
>>>>>>>                
>>>>>> I don't understand why the constraints of real h/w have anything to do
>>>>>> with this.  Can you explain?
>>>>>>
>>>>>>              
>>>>> Each time we do something not architectural it cause us troubles later.
>>>>> So constraints of real h/w is our constrains to.
>>>>>            
>>>> Your constraints are purely artificial.
>>>>
>>>>          
>>> What is artificial about it? Each time we break them we safer.
>>>        
>> Just because something doesn't fit as an ISA or PCI device doesn't
>> mean it can't exist in real life.  There are plenty of one-off
>> devices with odd interfaces.
>>      
> And there are such that cause cpu to stall for 6.5 seconds when you do
> io to them?

That would certainly be a poorly designed interface.  I can appreciate 
your point and I think suggesting that we should implement an ad-hoc 
completion interface is reasonable.  For instance,

outl(FW_CFG_SET_INITRD_ADDR, addr)
while !inb(FW_CFG_INITRD_READY):
      // spin

>>>> There are plenty of places that something like fw_cfg could live and
>>>> still do DMA.  It can directly hang off of the Southbridge.  It
>>>> doesn't necessary need to be connected to the ISA/LPC buses.
>>>>          
>>> Examples of real HW?
>>>        
>> The IBM IMM, HP ILO, or Intel iAMT modules.  They basically play an
>> identical role to fw_cfg.
>>
>>      
> So what are their interfaces?  May be we should emulate one.
>    

The interface to firmware is private and changes from platform to 
platform.  The IMM exposes various interfaces to the OS as it implements 
a number of legacy devices.  It also exposes a side-channel (very 
similar to virtio-console) as a USB RNDIS driver.  I believe it 
implements IPMI over a private ethernet type although I'd have to double 
check.  It may actually use TCP/IP. Of course it is possible to add

>>> proper DMA interface to fw_cfg, but should we do it for such a small
>>> gain?
>>>        
>> I think an ad-hoc DMA interface is perfectly reasonable to do.  I
>> agree that adding a more generic DMA interface is overkill.
>>
>>      
> It should look like real DMA at least. The justification for it should
> be better than "In our project we don't what to do this and we don't
> what to do that so our initrd is 100M now, so why not add hack to qemu
> to load it 1 second faster so we can grow it some more".
>    

I certainly agree that adding a polling interface for DMA completion is 
a reasonable requirement.

Regards,

Anthony Liguori

> --
> 			Gleb.
>