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

[Anthony Liguori]

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.

> 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?

> 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.

Regards,

Anthony Liguori

>   While the first three points could be improved with some effort, 
> adding a new dma interface is not going to be orthogonal to virtio.  
> And frankly, libguestfs is better off switching to one of the other 
> interfaces.  Slurping huge initrds isn't the right way to do this.
>
> > As a side note, we ought to do a better job of removing features that 
> > have created a burden on other areas of qemu that aren't actively 
> > being maintained.  That's a different discussion though.
>
> Sure, we need something like Linux' 
> Documentation/feature-removal-schedule.txt for people to ignore.