summaryrefslogtreecommitdiffstats
path: root/drivers/xen/platform-pci.c
diff options
context:
space:
mode:
authorBoris Ostrovsky <boris.ostrovsky@oracle.com>2017-04-24 21:04:53 +0200
committerJuergen Gross <jgross@suse.com>2017-05-02 11:18:05 +0200
commit84d582d236dc1f9085e741affc72e9ba061a67c2 (patch)
tree7d012e4f1739b44c0bb5373a091a6f195c057d82 /drivers/xen/platform-pci.c
parentxen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams() (diff)
downloadlinux-84d582d236dc1f9085e741affc72e9ba061a67c2.tar.xz
linux-84d582d236dc1f9085e741affc72e9ba061a67c2.zip
xen: Revert commits da72ff5bfcb0 and 72a9b186292d
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741) established that commit 72a9b186292d ("xen: Remove event channel notification through Xen PCI platform device") (and thus commit da72ff5bfcb0 ("partially revert "xen: Remove event channel notification through Xen PCI platform device"")) are unnecessary and, in fact, prevent HVM guests from booting on Xen releases prior to 4.0 Therefore we revert both of those commits. The summary of that discussion is below: Here is the brief summary of the current situation: Before the offending commit (72a9b186292): 1) INTx does not work because of the reset_watches path. 2) The reset_watches path is only taken if you have Xen > 4.0 3) The Linux Kernel by default will use vector inject if the hypervisor support. So even INTx does not work no body running the kernel with Xen > 4.0 would notice. Unless he explicitly disabled this feature either in the kernel or in Xen (and this can only be disabled by modifying the code, not user-supported way to do it). After the offending commit (+ partial revert): 1) INTx is no longer support for HVM (only for PV guests). 2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have vector injection support. Since the only other mode supported is INTx which. So based on this summary, I think before commit (72a9b186292) we were in much better position from a user point of view. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
Diffstat (limited to 'drivers/xen/platform-pci.c')
-rw-r--r--drivers/xen/platform-pci.c14
1 files changed, 4 insertions, 10 deletions
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 2a165cc8a43c..1275df83070f 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -90,8 +90,10 @@ static int xen_allocate_irq(struct pci_dev *pdev)
static int platform_pci_resume(struct pci_dev *pdev)
{
int err;
- if (!xen_pv_domain())
+
+ if (xen_have_vector_callback)
return 0;
+
err = xen_set_callback_via(callback_via);
if (err) {
dev_err(&pdev->dev, "platform_pci_resume failure!\n");
@@ -137,15 +139,7 @@ static int platform_pci_probe(struct pci_dev *pdev,
platform_mmio = mmio_addr;
platform_mmiolen = mmio_len;
-
- /*
- * Xen HVM guests always use the vector callback mechanism.
- * L1 Dom0 in a nested Xen environment is a PV guest inside in an
- * HVM environment. It needs the platform-pci driver to get
- * notifications from L0 Xen, but it cannot use the vector callback
- * as it is not exported by L1 Xen.
- */
- if (xen_pv_domain()) {
+ if (!xen_have_vector_callback) {
ret = xen_allocate_irq(pdev);
if (ret) {
dev_warn(&pdev->dev, "request_irq failed err=%d\n", ret);