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

[Alexander Graf]

On 19.07.2010, at 10:01, Gleb Natapov wrote:

> On Mon, Jul 19, 2010 at 09:57:02AM +0200, Alexander Graf wrote:
>> 
>> 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.
>> 
> Loading huge initrd on real HW takes noticeably longer time that small
> one, so I would say that it is your design that is to blame here, not
> KVM.

I disagree. Virtualization enables new use cases. The -initrd parameter is a 
very good example for that. It's something that you simply couldn't do on real 
hw.

> 
>>> 
>>>> 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.
>> 
> We shouldn't add devices that work not like real HW to speed up some
> pathological cases (and are slow on real HW too).

Just because you don't use them doesn't mean they're pathological, really. We 
simply chose a bad interface for transferring reasonable big chunks of data and 
we need to fix that. If you want to look at it from a different perspective, 
it's a regression. Older qemu versions did map the kernel and initrd directly 
into guest ram, so now we're slower than back then.


Alex