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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 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.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux