diff options
author | David Woodhouse <dwmw@amazon.co.uk> | 2021-01-13 13:26:02 +0000 |
---|---|---|
committer | Juergen Gross <jgross@suse.com> | 2021-01-13 16:12:00 +0100 |
commit | 3499ba8198cad47b731792e5e56b9ec2a78a83a2 (patch) | |
tree | f2573188a2e7ee7847c1389a9bc8cd15bf5b2484 /lib/test_parman.c | |
parent | ef3a575baf53571dc405ee4028e26f50856898e7 (diff) | |
download | linux-3499ba8198cad47b731792e5e56b9ec2a78a83a2.tar.gz linux-3499ba8198cad47b731792e5e56b9ec2a78a83a2.tar.bz2 linux-3499ba8198cad47b731792e5e56b9ec2a78a83a2.zip |
xen: Fix event channel callback via INTX/GSI
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions below 4.0 because we avoid
calling xs_reset_watches() anyway, because xenstore might not cope with
reading a non-existent key. And newer Xen *does* have the vector
callback support, so we rarely fall back to INTX/GSI delivery.
To fix it, clean up a bit of the mess of xs_init() and xenbus_probe()
startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM
case, deferring it to be called from xenbus_probe() in the XS_HVM case
instead.
Then fix up the invocation of xenbus_probe() to happen either from its
device_initcall if the callback is available early enough, or when the
callback is finally set up. This means that the hack of calling
xenbus_probe() from a workqueue after the first interrupt, or directly
from the PCI platform device setup, is no longer needed.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20210113132606.422794-2-dwmw2@infradead.org
Signed-off-by: Juergen Gross <jgross@suse.com>
Diffstat (limited to 'lib/test_parman.c')
0 files changed, 0 insertions, 0 deletions