On 08/03/2010 02:05 PM, Gleb Natapov wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, 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.
+1. I already proposed that. Nobody objects against fast fast
communication channel between guest and host. In fact we have one:
virtio-serial. Of course it is much easier to hack dma semantic into
fw_cfg interface than add virtio-serial to seabios, but it doesn't make
it right. Does virtio-serial has to be exposed as PCI to a guest or can
we expose it as ISA device too in case someone want to use -kernel option
but do not see additional PCI device in a guest?
fw_cfg has to be available pretty early on so relying on a PCI device
isn't reasonable. Having dual interfaces seems wasteful.
We're already doing bulk data transfer over fw_cfg as we need to do it
to transfer roms and potentially a boot splash. Even outside of loading
an initrd, the performance is going to start to matter with a large
number of devices.
Regards,
Anthony Liguori
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html