virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Carsten Otte <cotte@de.ibm.com>, KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v3 0/5] kvm: Make ioeventfd usable on s390.
Date: Tue, 26 Feb 2013 13:18:12 +0200	[thread overview]
Message-ID: <20130226111812.GA11111@redhat.com> (raw)
In-Reply-To: <20130226110421.GB10915@redhat.com>

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 <mst@redhat.com>

---

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,

  reply	other threads:[~2013-02-26 11:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1361806070-62465-1-git-send-email-cornelia.huck@de.ibm.com>
2013-02-26 11:04 ` [PATCH v3 0/5] kvm: Make ioeventfd usable on s390 Michael S. Tsirkin
2013-02-26 11:18   ` Michael S. Tsirkin [this message]
2013-02-26 11:54     ` Christian Borntraeger
2013-02-26 12:13     ` Christian Borntraeger
2013-02-26 13:29       ` Cornelia Huck
2013-02-26 13:41       ` Michael S. Tsirkin
2013-02-26 13:48         ` Christian Borntraeger
2013-02-26 13:57           ` Michael S. Tsirkin
     [not found]       ` <20130226142907.3a38659f@gondolin>
2013-02-26 13:56         ` Michael S. Tsirkin
2013-02-26 14:05           ` Cornelia Huck
2013-02-27 19:49     ` Christian Borntraeger
2013-03-07 18:02     ` virtio-s390: document GPR4/GPR2 cookie values Michael S. Tsirkin
2013-03-08  7:55       ` Cornelia Huck
2013-03-12  3:47         ` Rusty Russell
2013-02-26 11:29   ` [PATCH v3 0/5] kvm: Make ioeventfd usable on s390 Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130226111812.GA11111@redhat.com \
    --to=mst@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).