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

[Alexander Graf]

On 19.07.2010, at 09:51, Gleb Natapov wrote:

> On Mon, Jul 19, 2010 at 09:40:18AM +0200, Alexander Graf wrote:
>> 
>> On 19.07.2010, at 09:33, 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.
>>> 
>>>>> Also 1 second on 100M file does not look like huge gain to me.
>>>> 
>>>> Every second counts.  We're trying to get libguestfs boot times down
>>>> from 8-12 seconds to 4-5 seconds.  For many cases it's an interactive
>>>> program.
>>>> 
>>> So what about making initrd smaller? I remember managing two
>>> distribution in 64M flash in embedded project.
>> 
>> Having a huge initrd basically helps in reusing a lot of existing code. We 
>> do the same - in general the initrd is just a subset of the applications of 
>> the host OS. And if you start putting perl or the likes into it, it becomes 
>> big.
>> 
> Why not provide small disk/cdrom with all those utilities installed?

Because - if the loading is done fast - this way everything's in RAM instantly. 
And you still have all devices available for use inside the system - that makes 
enumeration a lot easier. There are several reasons why and I don't think we 
should force different ways on people just because one component of our system 
is ineffective.

> 
>> I guess the best thing for now really is to try and see which code paths 
>> insb goes along. It should really be coalesced.
>> 
> It is coalesced to a certain extent (reenter guest every 1024 bytes,
> read from userspace page at a time). You need to continue injecting
> interrupt into a guest during long string operation and checking
> exception condition on a page boundaries.

That still sounds slow. So yeah, adding DMA is probably the right way to go. 
But then again - if we model it after real hw it would be asynchronous, giving 
us an interrupt, causing even more headache. Ugh.

Can't we just ignore real hw constraints here and have it available in guest 
ram once one particular PIO is done? No bus master, no interrupts, but full 
speed and simplicity/atomicity which also helps migration.

Alex