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