Messages in this thread | | | Date | Fri, 20 Oct 2023 10:51:41 +0200 | Subject | Re: [PATCH] hvc/xen: fix event channel handling for secondary consoles | From | Juergen Gross <> |
| |
On 18.10.23 01:46, David Woodhouse wrote: > From: David Woodhouse <dwmw@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@amazon.co.uk> > Cc: stable@vger.kernel.org
With above fixed in the commit message:
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
[unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] | |