From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver. Date: Tue, 14 Aug 2012 13:03:34 +0200 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87ipcms59i.fsf@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-Archive: List-Post: To: Rusty Russell Cc: KVM , linux-s390 , qemu-devel , Avi Kivity , Marcelo Tosatti , Anthony Liguori , Christian Borntraeger , Carsten Otte , Alexander Graf , Heiko Carstens , Martin Schwidefsky , Sebastian Ott List-ID: On Tue, 14 Aug 2012 09:40:01 +0930 Rusty Russell wrote: > On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck wrote: > > On Wed, 08 Aug 2012 13:52:57 +0930 > > Rusty Russell wrote: > > > > > On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck wrote: > > > 1) Please don't limit yourself to 32 feature bits! If you look at how > > > virtio_mmio does it, they use a selector to index into a > > > theoretically-infinite array of feature bits: > > > > It should be easy to extend the data processed by the feature ccws to a > > feature/index combination. Would it be practical to limit the index to > > an 8 bit value? > > 256 feature bits? That seems like it could one day be limiting. Or an > 8 bit accessor into feature words? 8192 seems enough for anyone sane. An 8 bit accessor. I hope everybody stays on the sane side :) > > > > Note that we're also speculating a move to a new vring format, which > > > will probably be little-endian. But you probably want a completely new > > > ccw code for that anyway. > > > > Do you have a pointer to that discussion handy? > > > > If the host may support different vring formats, I'll probably want to > > add some kind of discovery mechanism for that as well (what discovery > > mechanism depends on whether this would be per-device or per-machine). > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1Euc-0004bb-Gn for qemu-devel@nongnu.org; Tue, 14 Aug 2012 07:03:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1Eua-0003hN-Du for qemu-devel@nongnu.org; Tue, 14 Aug 2012 07:03:50 -0400 Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:59220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1Eua-0003hA-5g for qemu-devel@nongnu.org; Tue, 14 Aug 2012 07:03:48 -0400 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 14 Aug 2012 12:03:46 +0100 Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7EB3VKq27132104 for ; Tue, 14 Aug 2012 11:03:31 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7EB3anj032538 for ; Tue, 14 Aug 2012 05:03:36 -0600 Date: Tue, 14 Aug 2012 13:03:34 +0200 From: Cornelia Huck Message-ID: <20120814130334.79ba51b5@BR9GNB5Z> In-Reply-To: <87ipcms59i.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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Rusty Russell 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 09:40:01 +0930 Rusty Russell wrote: > On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck wrote: > > On Wed, 08 Aug 2012 13:52:57 +0930 > > Rusty Russell wrote: > > > > > On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck wrote: > > > 1) Please don't limit yourself to 32 feature bits! If you look at how > > > virtio_mmio does it, they use a selector to index into a > > > theoretically-infinite array of feature bits: > > > > It should be easy to extend the data processed by the feature ccws to a > > feature/index combination. Would it be practical to limit the index to > > an 8 bit value? > > 256 feature bits? That seems like it could one day be limiting. Or an > 8 bit accessor into feature words? 8192 seems enough for anyone sane. An 8 bit accessor. I hope everybody stays on the sane side :) > > > > Note that we're also speculating a move to a new vring format, which > > > will probably be little-endian. But you probably want a completely new > > > ccw code for that anyway. > > > > Do you have a pointer to that discussion handy? > > > > If the host may support different vring formats, I'll probably want to > > add some kind of discovery mechanism for that as well (what discovery > > mechanism depends on whether this would be per-device or per-machine). > > 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.