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
