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: Mon, 13 Aug 2012 10:56:38 +0200 Message-ID: <20120813105638.66df14a4@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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87pq72t3ku.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 Wed, 08 Aug 2012 13:52:57 +0930 Rusty Russell wrote: > On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck wrote: > > Add a driver for kvm guests that matches virtual ccw devices provided > > by the host as virtio bridge devices. > > Hi Cornelia, > > OK, this is a good opportunity to fix some limitations, just as > we did for virtio_mmio (drivers/virtio/virtio_mmio.c). > > 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: > > * 0x010 R HostFeatures Features supported by the host > * 0x014 W HostFeaturesSel Set of host features to access via HostFeatures > * > * 0x020 W GuestFeatures Features activated by the guest > * 0x024 W GuestFeaturesSel Set of activated features to set via GuestFeatures 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? > > 2) Please also allow the guest to set the alignment for virtio ring > layout (it controls the spacing between the rings), eg: > > * 0x03c W QueueAlign Used Ring alignment for the current queue I think the set_vq ccw could be extended with that info. > > 3) Finally, make sure the guest can set the size of the queue, in case > it can't allocate the size the host suggests, eg: > > * 0x034 R QueueNumMax Maximum size of the currently selected queue > * 0x038 W QueueNum Queue size for the currently selected queue > > This means the host can suggest huge queues, knowing the guest won't > simply fail if it does so. Makes sense, I didn't like just failing to allocate either. The actual size could probably go into the set_vq ccw as well. > > 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). From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0qSf-0002if-Bd for qemu-devel@nongnu.org; Mon, 13 Aug 2012 04:57:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0qSd-0002vn-AE for qemu-devel@nongnu.org; Mon, 13 Aug 2012 04:57:21 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:46238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0qSd-0002vL-1U for qemu-devel@nongnu.org; Mon, 13 Aug 2012 04:57:19 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 13 Aug 2012 09:57:15 +0100 Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7D8uZDa22282304 for ; Mon, 13 Aug 2012 08:56:35 GMT Received: from d06av05.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7D8uems011822 for ; Mon, 13 Aug 2012 02:56:40 -0600 Date: Mon, 13 Aug 2012 10:56:38 +0200 From: Cornelia Huck Message-ID: <20120813105638.66df14a4@BR9GNB5Z> In-Reply-To: <87pq72t3ku.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> 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 Wed, 08 Aug 2012 13:52:57 +0930 Rusty Russell wrote: > On Tue, 7 Aug 2012 16:52:47 +0200, Cornelia Huck wrote: > > Add a driver for kvm guests that matches virtual ccw devices provided > > by the host as virtio bridge devices. > > Hi Cornelia, > > OK, this is a good opportunity to fix some limitations, just as > we did for virtio_mmio (drivers/virtio/virtio_mmio.c). > > 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: > > * 0x010 R HostFeatures Features supported by the host > * 0x014 W HostFeaturesSel Set of host features to access via HostFeatures > * > * 0x020 W GuestFeatures Features activated by the guest > * 0x024 W GuestFeaturesSel Set of activated features to set via GuestFeatures 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? > > 2) Please also allow the guest to set the alignment for virtio ring > layout (it controls the spacing between the rings), eg: > > * 0x03c W QueueAlign Used Ring alignment for the current queue I think the set_vq ccw could be extended with that info. > > 3) Finally, make sure the guest can set the size of the queue, in case > it can't allocate the size the host suggests, eg: > > * 0x034 R QueueNumMax Maximum size of the currently selected queue > * 0x038 W QueueNum Queue size for the currently selected queue > > This means the host can suggest huge queues, knowing the guest won't > simply fail if it does so. Makes sense, I didn't like just failing to allocate either. The actual size could probably go into the set_vq ccw as well. > > 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).