All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Steve Rutherford <srutherford@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, ahonig@google.com
Subject: Re: [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference
Date: Thu, 14 May 2015 16:35:19 -0600	[thread overview]
Message-ID: <1431642919.3625.148.camel@redhat.com> (raw)
In-Reply-To: <20150514221041.GA21835@google.com>

On Thu, 2015-05-14 at 15:10 -0700, Steve Rutherford wrote:
> On Thu, May 14, 2015 at 10:04:40AM -0600, Alex Williamson wrote:
> > On Thu, 2015-05-14 at 17:46 +0200, Paolo Bonzini wrote:
> > > 
> > > On 14/05/2015 17:23, Alex Williamson wrote:
> > > > > Would irq_ack_notifiers be used at all with this patch set?  Resampling
> > > > > of IOAPIC level-triggered interrupts would be implemented in userspace.
> > > > >  For the same reason, assigned devices using legacy device assignment
> > > > > probably would not be able to use INTX (so this feature should depend on
> > > > > !KVM_DEVICE_ASSIGNMENT).  Add the emulated i8254 and the last user of
> > > > > irq_ack_notifiers goes away.
> > > > > 
> > > > > Alex, how does VFIO do INTX resampling if you're using TCG or -machine
> > > > > kernel_irqchip=off?  (Context: this series keeps the local APIC
> > > > > emulation in the kernel, thus including MSI, but moves the IOAPIC
> > > > > emualtion to userspace).
> > > > 
> > > > Without KVM irqchip, we use a rudimentary approach where we disable
> > > > mmaps to the device when an interrupt occurs.  This makes us trap all
> > > > accesses to the device.  We then handle any device access from the guest
> > > > as a potential EOI and unmask the interrupt.  If the interrupt re-fires,
> > > > we've at least rate-limited it.  If it doesn't, a timer eventually
> > > > re-enables devices mmaps.  It's not very efficient, but it works (for
> > > > both PCI and platform devices) and avoids IRQ APIs through QEMU that get
> > > > very platform/machine specific.  Thanks,
> > > 
> > > If we move the IOAPIC back to userspace, it probably would be easier to
> > > implement irqfd/resamplefd in userspace as well.  Let the bikeshedding
> > > start!
> > 
> > The current solution is merely functional with the benefit of being
> > architecture and machine-type independent.  If someone actually cared
> > about vfio assigned device performance without KVM irqchip, we'd
> > certainly need a more deterministic and efficient EOI path.  Thanks,
> > 
> > Alex
> > 
> 
> I'd like this feature to not preclude fast /modern/ device assignment
> (i.e. devices using MSIs). A perf hit (or even incompatibility) for
> legacy devices is fine [that's sort of the premise of this patchset].
> What's necessary for the device assignment to work with the split
> irqchip?

The current code will attempt to use kvm_irqchip_add_msi_route() and
kvm_irqchip_add_irqfd_notifier() to route the MSI through the KVM
irqchip.  Without that, QEMU will receive the MSI eventfd and call
msi_notify() or msix_notify(), which would be significantly slower.
This should be pretty much the same as virtio, which you've hopefully
already taken into consideration.  Thanks,

Alex


  reply	other threads:[~2015-05-14 22:35 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  1:47 [RFC PATCH 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP Steve Rutherford
2015-05-13  1:47 ` [RFC PATCH 2/4] KVM: x86: Add KVM exit for IOAPIC EOIs Steve Rutherford
2015-05-13  7:35   ` Paolo Bonzini
2015-05-13 22:18     ` Steve Rutherford
2015-05-24 16:46   ` Avi Kivity
2015-05-27  2:06     ` Steve Rutherford
2015-05-27  5:32       ` Avi Kivity
2015-05-28 21:58         ` Steve Rutherford
2015-05-13  1:47 ` [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference Steve Rutherford
2015-05-13  6:12   ` Jan Kiszka
2015-05-13  8:04     ` Paolo Bonzini
2015-05-13  8:10       ` Jan Kiszka
2015-05-13  9:24         ` Paolo Bonzini
2015-05-13 10:25           ` Jan Kiszka
2015-05-13 13:04             ` Paolo Bonzini
2015-05-13 13:19               ` Jan Kiszka
2015-05-13 22:21       ` Steve Rutherford
2015-05-15  2:38       ` Steve Rutherford
2015-05-13  7:51   ` Paolo Bonzini
2015-05-13 22:24     ` Steve Rutherford
2015-05-14  9:20       ` Paolo Bonzini
2015-05-14 15:23         ` Alex Williamson
2015-05-14 15:46           ` Paolo Bonzini
2015-05-14 16:04             ` Alex Williamson
2015-05-14 22:10               ` Steve Rutherford
2015-05-14 22:35                 ` Alex Williamson [this message]
2015-05-14 23:21                   ` Steve Rutherford
2015-05-13  1:47 ` [RFC PATCH 4/4] KVM: x86: Add support for local interrupt requests from userspace Steve Rutherford
2015-05-13  6:12   ` Jan Kiszka
2015-05-13 22:41     ` Steve Rutherford
2015-05-15 13:27       ` Jan Kiszka
2015-05-13  7:22   ` Paolo Bonzini
2015-05-13 23:13     ` Steve Rutherford
2015-05-13  7:57 ` [RFC PATCH 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP Paolo Bonzini
2015-05-13 22:10   ` Steve Rutherford
2015-05-14  9:12     ` Wu, Feng
2015-05-14 19:29       ` Andrew Honig
2015-05-15  1:28         ` Wu, Feng
2015-05-15  5:03         ` Wanpeng Li
2015-05-15 18:10           ` Steve Rutherford
2015-05-18  2:11             ` Wanpeng Li

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=1431642919.3625.148.camel@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=ahonig@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=srutherford@google.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 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.