From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver. Date: Wed, 15 Aug 2012 12:45:26 +0930 Message-ID: <87r4r8rgkx.fsf@rustcorp.com.au> References: <1344351168-2568-1-git-send-email-cornelia.huck@de.ibm.com> <1344351168-2568-4-git-send-email-cornelia.huck@de.ibm.com> <87pq72t3ku.fsf@rustcorp.com.au> <20120813105638.66df14a4@BR9GNB5Z> <87ipcms59i.fsf@rustcorp.com.au> <20120814130334.79ba51b5@BR9GNB5Z> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20120814130334.79ba51b5@BR9GNB5Z> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Archive: List-Post: To: Cornelia Huck Cc: linux-s390 , Anthony Liguori , KVM , Carsten Otte , Sebastian Ott , Marcelo Tosatti , Heiko Carstens , qemu-devel , Alexander Graf , Christian Borntraeger , Avi Kivity , Martin Schwidefsky List-ID: On Tue, 14 Aug 2012 13:03:34 +0200, Cornelia Huck wrote: > > It would be per-machine; per-device would be a bit crazy. We'd > > deprecate the old ring format. > > > > There's been no consistent thread on the ideas for a ring change, > > unfortunately, but you can find interesting parts here, off this thread: > > > > Message-ID: <8762gj6q5r.fsf@rustcorp.com.au> > > Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver. > > I've read a bit through this and it looks like this is really virtio-2 > or so. How about discoverability by the guest? Guests will likely have > to support both formats, and forcing them to look at the feature bits > for each device in order to figure out the queue format feels wrong if > it is going to be the same format for the whole machine anyway. Yes, it needs some out-of-band acknowledgement mechanism by the guest. Might be worth putting a max version number somewhere, which the guest writes to acknowledge (ie. currently it would be 1, and the guest would always write a 1). Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1Ue8-0008K6-Vw for qemu-devel@nongnu.org; Tue, 14 Aug 2012 23:51:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1Ue7-0005sD-RI for qemu-devel@nongnu.org; Tue, 14 Aug 2012 23:51:52 -0400 Received: from ozlabs.org ([203.10.76.45]:56307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1Ue7-0005rs-FO for qemu-devel@nongnu.org; Tue, 14 Aug 2012 23:51:51 -0400 From: Rusty Russell In-Reply-To: <20120814130334.79ba51b5@BR9GNB5Z> References: <1344351168-2568-1-git-send-email-cornelia.huck@de.ibm.com> <1344351168-2568-4-git-send-email-cornelia.huck@de.ibm.com> <87pq72t3ku.fsf@rustcorp.com.au> <20120813105638.66df14a4@BR9GNB5Z> <87ipcms59i.fsf@rustcorp.com.au> <20120814130334.79ba51b5@BR9GNB5Z> Date: Wed, 15 Aug 2012 12:45:26 +0930 Message-ID: <87r4r8rgkx.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: linux-s390 , Anthony Liguori , KVM , Carsten Otte , Sebastian Ott , Marcelo Tosatti , Heiko Carstens , qemu-devel , Alexander Graf , Christian Borntraeger , Avi Kivity , Martin Schwidefsky On Tue, 14 Aug 2012 13:03:34 +0200, Cornelia Huck wrote: > > It would be per-machine; per-device would be a bit crazy. We'd > > deprecate the old ring format. > > > > There's been no consistent thread on the ideas for a ring change, > > unfortunately, but you can find interesting parts here, off this thread: > > > > Message-ID: <8762gj6q5r.fsf@rustcorp.com.au> > > Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver. > > I've read a bit through this and it looks like this is really virtio-2 > or so. How about discoverability by the guest? Guests will likely have > to support both formats, and forcing them to look at the feature bits > for each device in order to figure out the queue format feels wrong if > it is going to be the same format for the whole machine anyway. Yes, it needs some out-of-band acknowledgement mechanism by the guest. Might be worth putting a max version number somewhere, which the guest writes to acknowledge (ie. currently it would be 1, and the guest would always write a 1). Cheers, Rusty.