All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernhard Beschow <shentey@gmail.com>
To: qemu-devel@nongnu.org, David Woodhouse <dwmw2@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>, Paul Durrant <paul@xen.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [PATCH] hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI
Date: Wed, 08 Jan 2025 09:45:43 +0000	[thread overview]
Message-ID: <E60B2E8D-23B5-43E2-8DC5-FDBA30EB40EF@gmail.com> (raw)
In-Reply-To: <8b2690f2c9532468fd5029d319737904b58acec2.camel@infradead.org>



Am 7. Januar 2025 16:20:28 UTC schrieb David Woodhouse <dwmw2@infradead.org>:
>On Tue, 2025-01-07 at 11:07 -0500, Michael S. Tsirkin wrote:
>> On Thu, Dec 19, 2024 at 05:24:11PM +0100, David Woodhouse wrote:
>> > From: David Woodhouse <dwmw@amazon.co.uk>
>> > 
>> > The system GSIs are not designed for sharing. One device might assert a
>> > shared interrupt with qemu_set_irq() and another might deassert it, and
>> > the level from the first device is lost.
>> > 
>> > This could be solved by using a multiplexer which functions as an OR
>> > gate, much like the PCI code already implements for pci_set_irq() for
>> > muxing the INTx lines.

Just curious: Why not use that aporoach? Could <https://lore.kernel.org/qemu-devel/20250108092538.11474-5-shentey@gmail.com/> help?

Best regards,
Bernhard

>> > 
>> > Alternatively, it could be solved by having a 'resample' callback which
>> > is invoked when the interrupt is acked at the interrupt controller, and
>> > causes the devices to re-trigger the interrupt if it should still be
>> > pending. This is the model that VFIO in Linux uses, with a 'resampler'
>> > eventfd that actually unmasks the interrupt on the hardware device and
>> > thus triggers a new interrupt from it if needed. QEMU currently doesn't
>> > use that VFIO interface correctly, and just bashes on the resampler for
>> > every MMIO access to the device "just in case".
>> > 
>> > This does neither of those. The Xen event channel GSI support *already*
>> > has hooks into the PC gsi_handler() code, for routing GSIs to PIRQs. So
>> > we can implement the logical OR of the external input (from PCI INTx,
>> > serial etc.) with the Xen event channel GSI by allowing that existing
>> > hook to modify the 'level' being asserted.
>> > 
>> > Closes: https://gitlab.com/qemu-project/qemu/-/issues/2731
>> > Reported-by: Thomas Huth <thuth@redhat.com>
>> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>> 
>> Xen things so feel free to merge.
>> 
>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
>Thanks.
>
>Further testing shows I need one minor fix...
>
>> > @@ -1596,7 +1607,7 @@ static int allocate_pirq(XenEvtchnState *s, int type, int gsi)
>> >      return pirq;
>> >  }
>> >  
>> > -bool xen_evtchn_set_gsi(int gsi, int level)
>> > +bool xen_evtchn_set_gsi(int gsi, int *level)
>> >  {
>> >      XenEvtchnState *s = xen_evtchn_singleton;
>> >      int pirq;
>
>...
>
>@@ -1628,7 +1656,7 @@ bool xen_evtchn_set_gsi(int gsi, int level)
>         return false;
>     }
> 
>-    if (level) {
>+    if (*level) {
>         int port = s->pirq[pirq].port;
> 
>         s->pirq_gsi_set |= (1U << gsi);
>
>
>


  reply	other threads:[~2025-01-08 10:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 16:24 [PATCH] hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI David Woodhouse
2025-01-06 16:00 ` David Woodhouse
2025-01-07 16:07 ` Michael S. Tsirkin
2025-01-07 16:20   ` David Woodhouse
2025-01-08  9:45     ` Bernhard Beschow [this message]
2025-01-08 11:26       ` David Woodhouse
2025-01-08 14:23         ` Bernhard Beschow

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=E60B2E8D-23B5-43E2-8DC5-FDBA30EB40EF@gmail.com \
    --to=shentey@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@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 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.