All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Dmytro Maluka <dmy@semihalf.com>
Cc: Auger Eric <eric.auger@redhat.com>,
	Micah Morton <mortonm@chromium.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Rong L Liu <rong.l.liu@intel.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	Grzegorz Jaszczyk <jaz@semihalf.com>,
	Dmitry Torokhov <dtor@google.com>
Subject: Re: Add vfio-platform support for ONESHOT irq forwarding?
Date: Thu, 7 Jul 2022 15:00:06 +0000	[thread overview]
Message-ID: <Ysb09r+XXcVZyok4@google.com> (raw)
In-Reply-To: <94423bc0-a6d3-f19f-981b-9da113e36432@semihalf.com>

On Thu, Jul 07, 2022, Dmytro Maluka wrote:
> Hi Sean,
> 
> On 7/6/22 10:39 PM, Sean Christopherson wrote:
> > On Wed, Jul 06, 2022, Dmytro Maluka wrote:
> > > This is not a problem on native, since for oneshot irq we keep the interrupt
> > > masked until the thread exits, so that the EOI at the end of hardirq doesn't
> > > result in immediate re-assert. In vfio + KVM case, however, the host doesn't
> > > check that the interrupt is still masked in the guest, so
> > > vfio_platform_unmask() is called regardless.
> > 
> > Isn't not checking that an interrupt is unmasked the real bug?  Fudging around vfio
> > (or whatever is doing the premature unmasking) bugs by delaying an ack notification
> > in KVM is a hack, no?
> 
> Yes, not checking that an interrupt is unmasked is IMO a bug, and my patch
> actually adds this missing checking, only that it adds it in KVM, not in
> VFIO. :)
> 
> Arguably it's not a bug that VFIO is not checking the guest interrupt state
> on its own, provided that the resample notification it receives is always a
> notification that the interrupt has been actually acked. That is the
> motivation behind postponing ack notification in KVM in my patch: it is to
> ensure that KVM "ack notifications" are always actual ack notifications (as
> the name suggests), not just "eoi notifications".

But EOI is an ACK.  It's software saying "this interrupt has been consumed".
 
> That said, your idea of checking the guest interrupt status in VFIO (or
> whatever is listening on the resample eventfd) makes sense to me too. The
> problem, though, is that it's KVM that knows the guest interrupt status, so
> KVM would need to let VFIO/whatever know it somehow. (I'm assuming we are
> focusing on the case of KVM kernel irqchip, not userspace or split irqchip.)
> So do you have in mind adding something like "maskfd" and "unmaskfd" to KVM
> IRQFD interface, in addition to resamplefd? If so, I'm actually in favor of
> such an idea, as I think it would be also useful for other purposes,
> regardless of oneshot interrupts.

Unless I'm misreading things, KVM already provides a mask notifier, irqfd just
needs to be wired up to use kvm_(un)register_irq_mask_notifier().

  reply	other threads:[~2022-07-07 15:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 15:46 Add vfio-platform support for ONESHOT irq forwarding? Micah Morton
2021-01-25 17:31 ` Auger Eric
2021-01-25 18:32   ` Micah Morton
2021-01-26  8:48     ` Auger Eric
2021-01-26 15:31       ` Micah Morton
2021-01-26 16:05         ` Auger Eric
2021-01-25 20:36 ` Alex Williamson
2021-01-26  8:53   ` Auger Eric
2021-01-26 15:15     ` Micah Morton
2021-01-26 16:19       ` Auger Eric
2021-01-27 15:58         ` Micah Morton
2021-01-29 19:57           ` Micah Morton
2021-01-30 16:38             ` Auger Eric
2022-07-06 15:25               ` Dmytro Maluka
2022-07-06 20:39                 ` Sean Christopherson
2022-07-07  7:38                   ` Dmytro Maluka
2022-07-07 15:00                     ` Sean Christopherson [this message]
2022-07-07 17:38                       ` Dmytro Maluka
2022-07-12 16:02                         ` Liu, Rong L
2022-08-04 14:44                           ` Eric Auger
2022-08-08 21:15                             ` Liu, Rong L
2022-07-07  8:25                 ` Eric Auger
2022-07-07  9:15                   ` Dmytro Maluka
2022-07-25 22:03                     ` Liu, Rong L
2022-08-04 14:39                       ` Eric Auger
2022-08-08 17:34                         ` Liu, Rong L

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=Ysb09r+XXcVZyok4@google.com \
    --to=seanjc@google.com \
    --cc=alex.williamson@redhat.com \
    --cc=dmy@semihalf.com \
    --cc=dtor@google.com \
    --cc=eric.auger@redhat.com \
    --cc=jaz@semihalf.com \
    --cc=kvm@vger.kernel.org \
    --cc=mortonm@chromium.org \
    --cc=pbonzini@redhat.com \
    --cc=rong.l.liu@intel.com \
    --cc=tn@semihalf.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.