From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgai0-0001tq-UA for qemu-devel@nongnu.org; Mon, 18 Jun 2012 08:05:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sgahq-0008PJ-T6 for qemu-devel@nongnu.org; Mon, 18 Jun 2012 08:05:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgahq-0008N4-LF for qemu-devel@nongnu.org; Mon, 18 Jun 2012 08:05:18 -0400 Date: Mon, 18 Jun 2012 15:05:04 +0300 From: "Michael S. Tsirkin" Message-ID: <20120618120503.GA25390@redhat.com> References: <20120319155650.GA6430@redhat.com> <4F6786C5.3080902@codemonkey.ws> <20120319204952.GA9747@redhat.com> <4F67A021.6040601@us.ibm.com> <20120319212916.GC9747@redhat.com> <4F67AF72.8080905@codemonkey.ws> <877gygqhbp.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877gygqhbp.fsf@rustcorp.com.au> Subject: Re: [Qemu-devel] [PATCH RFC] virtio-pci: add MMIO property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: Anthony Liguori , kvm@vger.kernel.org, Alexey Kardashevskiy , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, avi@redhat.com, Anthony Liguori On Tue, Mar 20, 2012 at 10:22:42AM +1030, Rusty Russell wrote: > On Mon, 19 Mar 2012 17:13:06 -0500, Anthony Liguori wrote: > > > Maybe just make this a hidden option like x-miio? > > > > x-violate-the-virtio-spec-to-trick-old-linux-drivers-into-working-on-power? > > "To configure the device, we use the first I/O region of the PCI > device." > > Meh, it does sound a little like we are specifying that it's an PCI I/O > bar. > > Let's resurrect the PCI-v2 idea, which is ready to implement now, and a > nice cleanup? Detach it from the change-of-ring-format idea which is > turning out to be a tarpit. > > Thanks, > Rusty. Yes. But it seems silly to even write code to play with device config in memory when we agreed the right thing to do is to use a config vq everywhere. Now a question: does a oconfig vq look like a PCI specific feature to you, a work-around for lack of multibyte atomic accesses? If yes it's sane to make it a PCI capability. Or is it something most transports would need? If yes we need a feature bit and this is a chicken and egg problem ... > -- > How could I marry someone with more hair than me? http://baldalex.org