[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <36c9298d-2052-42de-9ef4-135c120a2417@suse.com>
Date: Fri, 20 Oct 2023 10:51:41 +0200
From: Juergen Gross <jgross@...e.com>
To: David Woodhouse <dwmw2@...radead.org>,
xen-devel <xen-devel@...ts.xenproject.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Roger Pau Monne <roger.pau@...rix.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Dawei Li <set_pte_at@...look.com>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org, Paul Durrant <paul@....org>
Subject: Re: [PATCH] hvc/xen: fix event channel handling for secondary
consoles
On 18.10.23 01:46, David Woodhouse wrote:
> From: David Woodhouse <dwmw@...zon.co.uk>
>
> The xencons_connect_backend() function allocates a local interdomain
> event channel with xenbus_alloc_evtchn(), then calls
> bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
> *remote* domain.
>
> That doesn't work very well:
>
> (qemu) device_add xen-console,id=con1,chardev=pty0
> [ 44.323872] xenconsole console-1: 2 xenbus_dev_probe on device/console/1
> [ 44.323995] xenconsole: probe of console-1 failed with error -2
>
> Fix it to use bind_evtchn_to_irq_lateeoi(), which does the right thing
> by just binding that *local* event channel to an irq. The backend will
> do the interdomain binding.
>
> This didn't affect the primary console because the setup for that is
> special — the toolstack allocates the guest event channel and the guest
> discovers it with HVMOP_get_param.
>
> Once that's fixed, there's also a warning on hot-unplug because
> xencons_disconnect_backend() unconditionally calls free_irq() via
> unbind_from_irqhandler():
>
> (qemu) device_del con1
> [ 32.050919] ------------[ cut here ]------------
> [ 32.050942] Trying to free already-free IRQ 33
> [ 32.050990] WARNING: CPU: 0 PID: 51 at kernel/irq/manage.c:1895 __free_irq+0x1d4/0x330
>
> Fix that by calling notifier_del_irq() first, which only calls
> free_irq() if the irq was requested in the first place. Then use
I don't think the "if the irq was requested in the first place" is the correct
reasoning.
I think the problem is that notifier_del_irq() will be called another time
through the .notifier_del hook. Two calls of notifier_del_irq() are fine, but
one call of it and another call of free_irq() via unbind_from_irqhandler() is
a problem.
> evtchn_put() to release the irq and event channel. Avoid calling
> xenbus_free_evtchn() in the normal case, as evtchn_put() will do that
> too. The only time xenbus_free_evtchn() needs to be called is for the
> cleanup when bind_evtchn_to_irq_lateeoi() fails.
>
> Finally, fix the error path in xen_hvc_init() when there's no primary
> console. It should still register the frontend driver, as there may be
> secondary consoles. (Qemu can always add secondary consoles, but only
> the toolstack can add the primary because it's special.)
>
> Fixes: fe415186b4 ("xen/console: harden hvc_xen against event channel storms")
> Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
> Cc: stable@...r.kernel.org
With above fixed in the commit message:
Reviewed-by: Juergen Gross <jgross@...e.com>
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists