[PATCH] hvc/xen: fix event channel handling for secondary consoles

[Juergen Gross]

On 18.10.23 01:46, David Woodhouse wrote:
> From: David Woodhouse <dwmw at amazon.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 at amazon.co.uk>
> Cc: stable at vger.kernel.org

With above fixed in the commit message:

Reviewed-by: Juergen Gross <jgross at suse.com>


Juergen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB0DE9DD628BF132F.asc
Type: application/pgp-keys
Size: 3098 bytes
Desc: OpenPGP public key
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20231020/a9a679fe/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20231020/a9a679fe/attachment.sig>