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

[Avi Kivity <avi@redhat.com>]

  On 08/03/2010 09:55 PM, Anthony Liguori wrote:
> On 08/03/2010 01:43 PM, Avi Kivity wrote:
>>>
>>> If Richard is willing to do the work to make -kernel perform faster 
>>> in such a way that it fits into the overall mission of what we're 
>>> building, then I see no reason to reject it.  The criteria for 
>>> evaluating a patch should only depend on how it affects other areas 
>>> of qemu and whether it impacts overall usability.
>>
>> That's true, but extending fwcfg doesn't fit into the overall picture 
>> well.  We have well defined interfaces for pushing data into a guest: 
>> virtio-serial (dma upload), virtio-blk (adds demand paging), and 
>> virtio-p9fs (no image needed).  Adapting libguestfs to use one of 
>> these is a better move than adding yet another interface.
>
> On real hardware, there's an awful lot of interaction between the 
> firmware and the platform.  It's a pretty rich interface.  On IBM 
> systems, we actually extend that all the way down to userspace via a 
> virtual USB RNDIS driver that you can use IPMI over.

That is fine and we'll do pv interfaces when we have to.  That's fwfg, 
that's virtio.  But let's not do more than we have to.

>
>> A better (though still inaccurate) analogy is would be if the 
>> developers of a guest OS came up with a virtual bus for devices and 
>> were willing to do the work to make this bus perform better.  Would 
>> we accept this new work or would we point them at our existing bus 
>> (pci) instead?
>
> Doesn't this precisely describe virtio-s390?

As I understood it, s390 had good reasons not to use their native 
interfaces.  On x86 we have no good reason not to use pci and no good 
reason not to use virtio for dma.

>>
>> Really, the bar on new interfaces (both to guest and host) should be 
>> high, much higher than it is now.  Interfaces should be well 
>> documented, future proof, migration safe, and orthogonal to existing 
>> interfaces.
>
> Okay, but this is a bigger discussion that I'm very eager to have.  
> But we shouldn't explicitly apply new policies to random patches 
> without clearly stating the policy up front.
>

Migration safety has been part of the criteria for a while.  Future 
proofness less so.  Documentation was usually completely missing but I 
see no reason not to insist on it now, better late than never.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.