public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, Carsten Otte <cotte@de.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	virtualization@lists.linux-foundation.org, rusty@rustcorp.com.au
Subject: Re: [PATCH v3 0/5] kvm: Make ioeventfd usable on s390.
Date: Tue, 26 Feb 2013 12:29:58 +0100	[thread overview]
Message-ID: <512C9CB6.2090208@de.ibm.com> (raw)
In-Reply-To: <20130226110421.GB10915@redhat.com>

On 26/02/13 12:04, 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, this would certainly have the best scalability, but such
a change would require adotions to the virtio spec and getting this
fully tested till 3.9 seems somewhat dangerous. 
So I would prefer to actually improve the lookup (e.g. with a tree or hash)
in kvm_io_bus_write or something like that as a first step.

We also have some guests in the wild  (sles11sp3 beta) that already
use the current interface, so compatibility is already a an interesting
aspect (does being a beta counts?)

Just thinking loud here, we might be able to do this in a compatible way.
The vq number that we pass is 64bit, but we dont need such a big range. The
guest could use the upper 32 bit as a cookie (old code will have 0 ---> list
traversal). We must have a query cookie function, that will return 0 on
older qemus, though. Such an optimization could be added later on without
needing to rush.

Ideas, opinions?

Christian


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

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-25 15:27 [PATCH v3 0/5] kvm: Make ioeventfd usable on s390 Cornelia Huck
2013-02-25 15:27 ` [PATCH v3 1/5] KVM: Initialize irqfd from kvm_init() Cornelia Huck
2013-02-25 15:27 ` [PATCH v3 2/5] KVM: s390: Export virtio-ccw api Cornelia Huck
2013-02-25 15:27 ` [PATCH v3 3/5] KVM: Introduce KVM_VIRTIO_CCW_NOTIFY_BUS Cornelia Huck
2013-02-25 15:27 ` [PATCH v3 4/5] KVM: ioeventfd for virtio-ccw devices Cornelia Huck
2013-02-26 10:55   ` Michael S. Tsirkin
2013-02-26 11:55     ` Cornelia Huck
2013-02-26 14:20     ` [Qemu-devel] " Stefan Hajnoczi
2013-02-26 14:47       ` Cornelia Huck
2013-02-26 14:19   ` Stefan Hajnoczi
2013-02-25 15:27 ` [PATCH v3 5/5] KVM: s390: Wire up ioeventfd Cornelia Huck
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
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:56         ` Michael S. Tsirkin
2013-02-26 14:05           ` 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
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   ` Christian Borntraeger [this message]

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=512C9CB6.2090208@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=cornelia.huck@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=gleb@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    --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