Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/03/2010 03:00 PM, Richard W.M. Jones wrote:
> On Tue, Aug 03, 2010 at 10:22:22PM +0300, Avi Kivity wrote:
>    
>>   On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:
>>      
>>> On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
>>>        
>>>> libguestfs does not depend on an x86 architectural feature.
>>>> qemu-system-x86_64 emulates a PC, and PCs don't have -kernel.  We
>>>> should discourage people from depending on this interface for
>>>> production use.
>>>>          
>>> I really don't get this whole thing where we must slavishly
>>> emulate an exact PC ...
>>>        
>> This has two motivations:
>>
>> - documented interfaces: we suck at documentation.  We seldom
>> document.  Even when we do document something, the documentation is
>> often inaccurate, misleading, and incomplete.  While an "exact PC"
>> unfortunately doesn't exist, it's a lot closer to reality than, say,
>> an "exact Linux syscall interface".  If we adopt an existing
>> interface, we already have the documentation, and if there's a
>> conflict between the documentation and our implementation, it's
>> clear who wins (well, not always).
>>
>> - preexisting guests: if we design a new interface, we get to update
>> all guests; and there are many of them.  Whereas an "exact PC" will
>> be seen by the guest vendors as well who will then add whatever
>> support is necessary.
>>      
> On the other hand we end up with stuff like only being able to add 29
> virtio-blk devices to a single guest.  As best as I can tell, this
> comes from PCI

No, this comes from us being too clever for our own good and not 
following the way hardware does it.

All modern systems keep disks on their own dedicated bus.  In 
virtio-blk, we have a 1-1 relationship between disks and PCI devices.  
That's a perfect example of what happens when we try to "improve" things.

> , and this limit required a bunch of hacks when
> implementing virt-df.
>
> These are reasonable motivations, but I think they are partially about
> us:
>
> We could document things better and make things future-proof.  I'm
> surprised by how lacking the doc requirements are for qemu (compared
> to, hmm, libguestfs for example).
>    

We enjoy complaining about our lack of documentation more than we like 
actually writing documentation.

> We could demand that OSes write device drivers for more qemu devices
> -- already OS vendors write thousands of device drivers for all sorts
> of obscure devices, so this isn't really much of a demand for them.
> In fact, they're already doing it.
>    

So far, MS hasn't quite gotten the clue yet that they should write 
device drivers for qemu :-)  In fact, noone has.

Regards,

Anthony Liguori

> Rich.
>
>