From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication Date: Mon, 10 Aug 2009 11:59:31 -0500 Message-ID: <4A8051F3.7040400@codemonkey.ws> References: <20090805175713.GB28738@shareable.org> <4A79C8D9.5030606@codemonkey.ws> <20090806103843.GC9222@amit-x200.redhat.com> <4A7ADAC4.70902@codemonkey.ws> <20090806134103.GC11733@amit-x200.redhat.com> <4A7AE169.4000606@codemonkey.ws> <20090806140404.GA12083@amit-x200.redhat.com> <20090806173740.GA1178@shareable.org> <20090807063800.GA16769@amit-x200.redhat.com> <4A7C36D3.3040305@codemonkey.ws> <20090810065508.GA4499@amit-x200.redhat.com> <4A7FECCA.8080804@redhat.com> <4A801A7B.1020208@codemonkey.ws> <4A80287C.7050400@redhat.com> <4A802CA7.9020701@codemonkey.ws> <4A803E07.7080407@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Amit Shah , kvm@vger.kernel.org, qemu-devel@nongnu.org, Rusty Russell , "Richard W.M. Jones" , virtualization@lists.linux-foundation.org To: Gerd Hoffmann Return-path: Received: from mail-yw0-f193.google.com ([209.85.211.193]:58344 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932287AbZHJQ7g (ORCPT ); Mon, 10 Aug 2009 12:59:36 -0400 Received: by ywh31 with SMTP id 31so4061904ywh.4 for ; Mon, 10 Aug 2009 09:59:37 -0700 (PDT) In-Reply-To: <4A803E07.7080407@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gerd Hoffmann wrote: > Ok, lets rip out the in-kernel ioapic code then. It can (and has > been) done in userspace. The justification is performance although that's not really true anymore post TPR optimization. But FWIW, I opposed both the in-kernel apic and the in-kernel pit when they were introduced. If nothing else, I'm at least consistent :-) > The daemon increases the possibility of userspace bugs. How? > Seriously: Attaching a name tag to virtio-serial devices and have > them exposed via sysfs is probably *much* less code than a vmchannel > daemon. I strongly doubt that. >> If we really want >> vmchannel to be used by application developers, then we really need a >> libvmchannel. > > We need a sane solution developed and merged and not a new idea each > week. There is nothing sane about vmchannel. It's just an attempt to bypass QEMU which is going to introduce all sorts of complexities wrt migration, guest compatibility, etc. However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. I think it's the wrong solution for the use-case, and I always have, but that's independent of my willingness to merge it. Regards, Anthony Liguori