From patchwork Tue Feb 26 11:18:12 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 223203 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id EDDEB2C02A7 for ; Tue, 26 Feb 2013 22:18:27 +1100 (EST) Received: from localhost ([::1]:43400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAIYE-0001G7-0a for incoming@patchwork.ozlabs.org; Tue, 26 Feb 2013 06:18:26 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAIY0-0001F1-IS for qemu-devel@nongnu.org; Tue, 26 Feb 2013 06:18:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAIXu-0006tY-H4 for qemu-devel@nongnu.org; Tue, 26 Feb 2013 06:18:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAIXu-0006t5-9s for qemu-devel@nongnu.org; Tue, 26 Feb 2013 06:18:06 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1QBI1Fk031031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Feb 2013 06:18:01 -0500 Received: from redhat.com (vpn1-4-143.ams2.redhat.com [10.36.4.143]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id r1QBHuVA002437; Tue, 26 Feb 2013 06:17:57 -0500 Date: Tue, 26 Feb 2013 13:18:12 +0200 From: "Michael S. Tsirkin" To: Cornelia Huck Message-ID: <20130226111812.GA11111@redhat.com> References: <1361806070-62465-1-git-send-email-cornelia.huck@de.ibm.com> <20130226110421.GB10915@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130226110421.GB10915@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: Carsten Otte , rusty@rustcorp.com.au, KVM , Gleb Natapov , linux-s390 , Marcelo Tosatti , Heiko Carstens , Alexander Graf , qemu-devel , Christian Borntraeger , Martin Schwidefsky , virtualization@lists.linux-foundation.org Subject: Re: [Qemu-devel] [PATCH v3 0/5] kvm: Make ioeventfd usable on s390. X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Tue, Feb 26, 2013 at 01:04:21PM +0200, Michael S. Tsirkin wrote: > On Mon, Feb 25, 2013 at 04:27:45PM +0100, Cornelia Huck wrote: > > Here's the latest version of my patch series enabling ioeventfds > > on s390, again against kvm-next. > > > > Patches 1 and 2 (cleaning up initialization and exporting the virtio-ccw > > api) would make sense even independent of the ioeventfd enhancements. > > > > Patches 3-5 are concerned with adding a new type of ioeventfds for > > virtio-ccw notifications on s390. The naming is now hopefully clearer. > > We won't add ioeventfd support for the legacy s390-virtio transport. > > > > Please consider applying. > > I just had a thought: this makes us lookup the device on the bus > for each notification. It would be better to simply get the > device index from guest instead. > > We could validate that it matches the correct device, > if not - fallback to the current linear scan. > > We could return the index to guest for the next call. > > I know this needs guest changes but it's still not too late to > fix this for 3.9 guests so that we won't need to worry > about compatibility going forward. > > Hmm? And just to clarify, here's what I mean (BTW, why doesn't this code use the interfaces from kvm_para.h?) I think it's a good idea to merge this before 3.9 so we don't need to worry about legacy going forward. Completely untested, just to give you the idea. ---> virtio_ccw: pass a cookie value to kvm hypercall Lookups by channel/vq pair on host during virtio notifications might be expensive. Interpret hypercall return value as a cookie which host can use to do device lookups for the next notification more efficiently. Signed-off-by: Michael S. Tsirkin Acked-by: Christian Borntraeger Tested-by: Christian Borntraeger Reviewed-by: Christian Borntraeger diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c index 2029b6c..1054f3a 100644 --- a/drivers/s390/kvm/virtio_ccw.c +++ b/drivers/s390/kvm/virtio_ccw.c @@ -77,6 +77,7 @@ struct virtio_ccw_vq_info { void *queue; struct vq_info_block *info_block; struct list_head node; + long cookie; }; #define KVM_VIRTIO_CCW_RING_ALIGN 4096 @@ -145,15 +146,18 @@ static int ccw_io_helper(struct virtio_ccw_device *vcdev, } static inline long do_kvm_notify(struct subchannel_id schid, - unsigned long queue_index) + unsigned long queue_index, + long cookie) { register unsigned long __nr asm("1") = KVM_S390_VIRTIO_CCW_NOTIFY; register struct subchannel_id __schid asm("2") = schid; register unsigned long __index asm("3") = queue_index; register long __rc asm("2"); + register long __cookie asm("4") = cookie; asm volatile ("diag 2,4,0x500\n" - : "=d" (__rc) : "d" (__nr), "d" (__schid), "d" (__index) + : "=d" (__rc) : "d" (__nr), "d" (__schid), "d" (__index), + "d"(__cookie) : "memory", "cc"); return __rc; } @@ -166,7 +170,7 @@ static void virtio_ccw_kvm_notify(struct virtqueue *vq) vcdev = to_vc_device(info->vq->vdev); ccw_device_get_schid(vcdev->cdev, &schid); - do_kvm_notify(schid, virtqueue_get_queue_index(vq)); + info->cookie = do_kvm_notify(schid, virtqueue_get_queue_index(vq), info->cookie); } static int virtio_ccw_read_vq_conf(struct virtio_ccw_device *vcdev,