qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	qemu-devel@nongnu.org, Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v3 4/5] KVM: Kick resamplefd for split kernel irqchip
Date: Tue, 17 Mar 2020 17:41:08 -0400	[thread overview]
Message-ID: <20200317214108.GD233068@xz-x1> (raw)
In-Reply-To: <20200317150646.2718d3a6@w520.home>

On Tue, Mar 17, 2020 at 03:06:46PM -0600, Alex Williamson wrote:

[...]

> > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> > index 15747fe2c2..81a17cc2b8 100644
> > --- a/hw/intc/ioapic.c
> > +++ b/hw/intc/ioapic.c
> > @@ -236,8 +236,29 @@ void ioapic_eoi_broadcast(int vector)
> >          for (n = 0; n < IOAPIC_NUM_PINS; n++) {
> >              entry = s->ioredtbl[n];
> >  
> > -            if ((entry & IOAPIC_VECTOR_MASK) != vector ||
> > -                ((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) != IOAPIC_TRIGGER_LEVEL) {
> > +            if ((entry & IOAPIC_VECTOR_MASK) != vector) {
> > +                continue;
> > +            }
> > +
> > +            /*
> > +             * When IOAPIC is in the userspace while APIC is still in
> > +             * the kernel (i.e., split irqchip), we have a trick to
> > +             * kick the resamplefd logic for registered irqfds from
> > +             * userspace to deactivate the IRQ.  When that happens, it
> > +             * means the irq bypassed userspace IOAPIC (so the irr and
> > +             * remote-irr of the table entry should be bypassed too
> > +             * even if interrupt come).  Still kick the resamplefds if
> > +             * they're bound to the IRQ, to make sure to EOI the
> > +             * interrupt for the hardware correctly.
> > +             *
> > +             * Note: We still need to go through the irr & remote-irr
> > +             * operations below because we don't know whether there're
> > +             * emulated devices that are using/sharing the same IRQ.
> > +             */
> > +            kvm_resample_fd_notify(n);
> > +
> > +            if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) !=
> > +                IOAPIC_TRIGGER_LEVEL) {
> >                  continue;
> >              }
> >  
> 
> What's the logic for sending resampler notifies before testing if the
> ioapic entry is in level triggered mode?  vfio won't use this for
> anything other than level triggered.  Inserting it between these checks
> confused me and in my testing wasn't necessary.  Thanks,

I put it there to match the kernel implementation, and IIUC Paolo
agreed with that too:

https://patchwork.kernel.org/patch/11407441/#23190969

Since we've discussed a few times here, I think I can talk a bit more
on how I understand this in case I was wrong...

Even if we have the fact that all the existing devices that use this
code should be using level-triggered IRQs, however... *If* there comes
an edge-triggered INTx device and we assign it using vfio-pci, vfio
should also mask the IRQ after it generates (according to
vfio_intx_handler), is that right?  Then we still need to kick the
resamplefd for that does-not-exist device too to make sure it'll work?

Thanks,

> 
> Alex
> 
> > diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> > index 141342de98..583a976f8a 100644
> > --- a/include/sysemu/kvm.h
> > +++ b/include/sysemu/kvm.h
> > @@ -555,4 +555,8 @@ int kvm_set_one_reg(CPUState *cs, uint64_t id, void *source);
> >  int kvm_get_one_reg(CPUState *cs, uint64_t id, void *target);
> >  struct ppc_radix_page_info *kvm_get_radix_page_info(void);
> >  int kvm_get_max_memslots(void);
> > +
> > +/* Notify resamplefd for EOI of specific interrupts. */
> > +void kvm_resample_fd_notify(int gsi);
> > +
> >  #endif
> 

-- 
Peter Xu



  reply	other threads:[~2020-03-17 21:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 19:50 [PATCH v3 0/5] vfio/pci: Fix up breakage against split irqchip and INTx Peter Xu
2020-03-17 19:50 ` [PATCH v3 1/5] vfio/pci: Disable INTx fast path if using split irqchip Peter Xu
2020-03-17 22:57   ` Alex Williamson
2020-03-17 19:50 ` [PATCH v3 2/5] vfio/pci: Use kvm_irqchip_add_irqfd_notifier_gsi() for irqfds Peter Xu
2020-03-17 22:57   ` Alex Williamson
2020-03-17 19:50 ` [PATCH v3 3/5] KVM: Pass EventNotifier into kvm_irqchip_assign_irqfd Peter Xu
2020-03-17 22:58   ` Alex Williamson
2020-03-17 19:50 ` [PATCH v3 4/5] KVM: Kick resamplefd for split kernel irqchip Peter Xu
2020-03-17 21:06   ` Alex Williamson
2020-03-17 21:41     ` Peter Xu [this message]
2020-03-17 22:12       ` Alex Williamson
2020-03-17 22:41         ` Peter Xu
2020-03-17 22:49   ` [PATCH v3.1 " Peter Xu
2020-03-17 22:58     ` Alex Williamson
2020-03-17 19:50 ` [PATCH v3 5/5] Revert "vfio/pci: Disable INTx fast path if using split irqchip" Peter Xu
2020-03-17 22:58   ` Alex Williamson
2020-03-18  2:56 ` [PATCH v3 0/5] vfio/pci: Fix up breakage against split irqchip and INTx no-reply

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=20200317214108.GD233068@xz-x1 \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).