public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH] IO: Intelligent device lookup on bus
Date: Thu, 21 Jul 2011 12:49:22 +0300	[thread overview]
Message-ID: <4E27F622.5040609@redhat.com> (raw)
In-Reply-To: <1311237804.29708.17.camel@lappy>

On 07/21/2011 11:43 AM, Sasha Levin wrote:
> On Wed, 2011-07-20 at 14:43 +0200, Jan Kiszka wrote:
> >  On 2011-07-20 14:11, Sasha Levin wrote:
> >  >  Currently the method of dealing with an IO operation on a bus (PIO/MMIO)
> >  >  is to call the read or write callback for each device registered
> >  >  on the bus until we find a device which handles it.
> >  >
> >  >  Since the number of devices on a bus can be significant due to ioeventfds
> >  >  and coalesced MMIO zones, this leads to a lot of overhead on each IO
> >  >  operation.
> >  >
> >  >  Instead of registering devices, we now register ranges which points to
> >  >  a device. Lookup is done using an efficient bsearch instead of a linear
> >  >  search.
> >  >
> >  >  This should speed up all IO operations generated by the guest.
> >  >
> >  >  Cc: Avi Kivity<avi@redhat.com>
> >  >  Cc: Marcelo Tosatti<mtosatti@redhat.com>
> >  >  Signed-off-by: Sasha Levin<levinsasha928@gmail.com>
> >  >  ---
> >  >
> >  >  This patch depends on '[PATCH v3] MMIO: Make coalesced mmio use a device
> >  >  per zone'.
> >  >
> >  >   arch/x86/kvm/i8254.c      |    4 +-
> >  >   arch/x86/kvm/i8259.c      |    4 +-
> >  >   include/linux/kvm_host.h  |   18 ++++----
> >  >   virt/kvm/coalesced_mmio.c |    6 +--
> >  >   virt/kvm/eventfd.c        |    3 +-
> >  >   virt/kvm/ioapic.c         |   13 +-----
> >  >   virt/kvm/kvm_main.c       |  107 +++++++++++++++++++++++++++++++++++++++-----
> >  >   7 files changed, 115 insertions(+), 40 deletions(-)
> >  >
> >  >  diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
> >  >  index efad723..61d193c 100644
> >  >  --- a/arch/x86/kvm/i8254.c
> >  >  +++ b/arch/x86/kvm/i8254.c
> >  >  @@ -713,13 +713,15 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags)
> >  >   	kvm_register_irq_mask_notifier(kvm, 0,&pit->mask_notifier);
> >  >
> >  >   	kvm_iodevice_init(&pit->dev,&pit_dev_ops);
> >  >  -	ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS,&pit->dev);
> >  >  +	ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, KVM_PIT_BASE_ADDRESS,
> >  >  +					KVM_PIT_MEM_LENGTH,&pit->dev);
> >  >   	if (ret<  0)
> >  >   		goto fail;
> >  >
> >  >   	if (flags&  KVM_PIT_SPEAKER_DUMMY) {
> >  >   		kvm_iodevice_init(&pit->speaker_dev,&speaker_dev_ops);
> >  >   		ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS,
> >  >  +						KVM_SPEAKER_BASE_ADDRESS, 4,
> >  >   						&pit->speaker_dev);
> >  >   		if (ret<  0)
> >  >   			goto fail_unregister;
> >  >  diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
> >  >  index 19fe855..c2295af 100644
> >  >  --- a/arch/x86/kvm/i8259.c
> >  >  +++ b/arch/x86/kvm/i8259.c
> >  >  @@ -562,7 +562,9 @@ struct kvm_pic *kvm_create_pic(struct kvm *kvm)
> >  >   	*/
> >  >   	kvm_iodevice_init(&s->dev,&picdev_ops);
> >  >   	mutex_lock(&kvm->slots_lock);
> >  >  -	ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS,&s->dev);
> >  >  +	ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, 0x20, 2,&s->dev);
> >  >  +	ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, 0xa0, 2,&s->dev);
> >  >  +	ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, 0x4d0, 2,&s->dev);
> >
> >  This made me wonder if you are incorrectly registering the same device
> >  multiple times. kvm_io_bus_register_dev is no longer optimally
> >  describing what is done here: the registration of an IO range with the
> >  bus. And that range is handled by a specific device. Conceptually, a
> >  device is only attached once to some bus.
>
> I agree. My initial thoughts were to leave it this way to simplify
> registrations, but as you said - it makes it somewhat confusing.
>
> I'll modify kvm_io_bus_register_dev to receive an array or ranges
> instead of a single range.

Icky.  How about using multiple kvm_io_device for the pic instead?

Otherwise you'll get the destructor running multiple times.

Note you have to be prepared for the same range to be registered 
multiple times, due to ioeventfd's data match feature.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2011-07-21  9:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20 12:11 [PATCH] IO: Intelligent device lookup on bus Sasha Levin
2011-07-20 12:43 ` Jan Kiszka
2011-07-21  8:43   ` Sasha Levin
2011-07-21  9:49     ` Avi Kivity [this message]
2011-07-20 19:41 ` Marcelo Tosatti
2011-07-20 21:22   ` Sasha Levin
2011-07-21 10:05     ` Avi Kivity

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=4E27F622.5040609@redhat.com \
    --to=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=mtosatti@redhat.com \
    /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