mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-24 13:13:57 +08:00
ddc416cbc4
Which is a PV guest with auto page translation enabled and with vector callback. It is a cross between PVHVM and PV. The Xen side defines PVH as (from docs/misc/pvh-readme.txt, with modifications): "* the guest uses auto translate: - p2m is managed by Xen - pagetables are owned by the guest - mmu_update hypercall not available * it uses event callback and not vlapic emulation, * IDT is native, so set_trap_table hcall is also N/A for a PVH guest. For a full list of hcalls supported for PVH, see pvh_hypercall64_table in arch/x86/hvm/hvm.c in xen. From the ABI prespective, it's mostly a PV guest with auto translate, although it does use hvm_op for setting callback vector." Also we use the PV cpuid, albeit we can use the HVM (native) cpuid. However, we do have a fair bit of filtering in the xen_cpuid and we can piggyback on that until the hypervisor/toolstack filters the appropiate cpuids. Once that is done we can swap over to use the native one. We setup a Kconfig entry that is disabled by default and cannot be enabled. Note that on ARM the concept of PVH is non-existent. As Ian put it: "an ARM guest is 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).". As such these options (PVHVM, PVH) are never enabled nor seen on ARM compilations. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
47 lines
1.4 KiB
C
47 lines
1.4 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) && \
|
|
xen_have_vector_callback)
|
|
#else
|
|
#define xen_pvh_domain() (0)
|
|
#endif
|
|
#endif /* _XEN_XEN_H */
|