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

[Avi Kivity]

 On 08/03/2010 09:26 PM, Anthony Liguori wrote:
> On 08/03/2010 12:58 PM, Avi Kivity wrote:
> >  On 08/03/2010 08:42 PM, Anthony Liguori wrote:
> > > However, I don't think we can objectively differentiate between a 
> > > "major" and "minor" user.  Generally speaking, I would rather that 
> > > we not take the position of "you are a minor user therefore we're 
> > > not going to accommodate you".
> >
> > Again it's a matter of practicalities.  With have written virtio 
> > drivers for Windows and Linux, but not for FreeDOS or NetWare.  To 
> > speed up Windows XP we have (in qemu-kvm) kvm-tpr-opt.c that is a 
> > gross breach of decency, would we go to the same lengths to speed up 
> > Haiku?  I suggest that we would not.
>
> tpr-opt optimizes a legitimate dependence on the x86 architecture that 
> Windows has.  While the implementation may be grossly indecent, it 
> certainly fits the overall mission of what we're trying to do in qemu 
> and kvm which is emulate an architecture.
>
> You've invested a lot of time and effort into it because it's 
> important to you (or more specifically, your employer).  That's 
> because Windows is important to you.

Correct.

> If someone as adept and commit as you was heavily invested in Haiku 
> and was willing to implement something equivalent to tpr-opt and also 
> willing to do all of the work of maintaining it, then reject such a 
> patch would be a mistake.

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.

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

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?

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

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