forked from luck/tmp_suning_uos_patched
72a9b18629
Ever since commit254d1a3f02("xen/pv-on-hvm kexec: shutdown watches from old kernel") using the INTx interrupt from Xen PCI platform device for event channel notification would just lockup the guest during bootup. postcore_initcall now calls xs_reset_watches which will eventually try to read a value from XenStore and will get stuck on read_reply at XenBus forever since the platform driver is not probed yet and its INTx interrupt handler is not registered yet. That means that the guest can not be notified at this moment of any pending event channels and none of the per-event handlers will ever be invoked (including the XenStore one) and the reply will never be picked up by the kernel. The exact stack where things get stuck during xenbus_init: -xenbus_init -xs_init -xs_reset_watches -xenbus_scanf -xenbus_read -xs_single -xs_single -xs_talkv Vector callbacks have always been the favourite event notification mechanism since their introduction in commit38e20b07ef("x86/xen: event channels delivery on HVM.") and the vector callback feature has always been advertised for quite some time by Xen that's why INTx was broken for several years now without impacting anyone. Luckily this also means that event channel notification through INTx is basically dead-code which can be safely removed without impacting anybody since it has been effectively disabled for more than 4 years with nobody complaining about it (at least as far as I'm aware of). This commit removes event channel notification through Xen PCI platform device. Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Juergen Gross <jgross@suse.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: Julien Grall <julien.grall@citrix.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ross Lagerwall <ross.lagerwall@citrix.com> Cc: xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: Anthony Liguori <aliguori@amazon.com> Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
46 lines
1.3 KiB
C
46 lines
1.3 KiB
C
#ifndef _XEN_XEN_H
|
|
#define _XEN_XEN_H
|
|
|
|
enum xen_domain_type {
|
|
XEN_NATIVE, /* running on bare hardware */
|
|
XEN_PV_DOMAIN, /* running in a PV domain */
|
|
XEN_HVM_DOMAIN, /* running in a Xen hvm domain */
|
|
};
|
|
|
|
#ifdef CONFIG_XEN
|
|
extern enum xen_domain_type xen_domain_type;
|
|
#else
|
|
#define xen_domain_type XEN_NATIVE
|
|
#endif
|
|
|
|
#define xen_domain() (xen_domain_type != XEN_NATIVE)
|
|
#define xen_pv_domain() (xen_domain() && \
|
|
xen_domain_type == XEN_PV_DOMAIN)
|
|
#define xen_hvm_domain() (xen_domain() && \
|
|
xen_domain_type == XEN_HVM_DOMAIN)
|
|
|
|
#ifdef CONFIG_XEN_DOM0
|
|
#include <xen/interface/xen.h>
|
|
#include <asm/xen/hypervisor.h>
|
|
|
|
#define xen_initial_domain() (xen_domain() && \
|
|
xen_start_info && xen_start_info->flags & SIF_INITDOMAIN)
|
|
#else /* !CONFIG_XEN_DOM0 */
|
|
#define xen_initial_domain() (0)
|
|
#endif /* CONFIG_XEN_DOM0 */
|
|
|
|
#ifdef CONFIG_XEN_PVH
|
|
/* This functionality exists only for x86. The XEN_PVHVM support exists
|
|
* only in x86 world - hence on ARM it will be always disabled.
|
|
* N.B. ARM guests are neither PV nor HVM nor PVHVM.
|
|
* It's a bit like PVH but is different also (it's further towards the H
|
|
* end of the spectrum than even PVH).
|
|
*/
|
|
#include <xen/features.h>
|
|
#define xen_pvh_domain() (xen_pv_domain() && \
|
|
xen_feature(XENFEAT_auto_translated_physmap))
|
|
#else
|
|
#define xen_pvh_domain() (0)
|
|
#endif
|
|
#endif /* _XEN_XEN_H */
|