All of lore.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:29 UTC|newest]

Thread overview: 31+ 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: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
2013-02-27 19:49     ` Christian Borntraeger
2013-03-07 18:02     ` virtio-s390: document GPR4/GPR2 cookie values Michael S. Tsirkin
2013-03-07 18:02       ` [Qemu-devel] " Michael S. Tsirkin
2013-03-08  7:55       ` Cornelia Huck
2013-03-08  7:55         ` [Qemu-devel] " Cornelia Huck
2013-03-12  3:47         ` Rusty Russell
2013-03-12  3:47           ` [Qemu-devel] " Rusty Russell
2013-02-26 11:29   ` Christian Borntraeger [this message]
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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.