[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC PATCH 01/16] x86/xen: add xenhost_t interface
On 11.06.19 09:16, Ankur Arora wrote:
On 2019-06-07 8:04 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Add xenhost_t which will serve as an abstraction over Xen interfaces.
It co-exists with the PV/HVM/PVH abstractions (x86_init, hypervisor_x86,
pv_ops etc) and is meant to capture mechanisms for communication with
Xen so we could have different types of underlying Xen: regular, local,
and nested.
Also add xenhost_register() and stub registration in the various guest
types.
Signed-off-by: Ankur Arora <ankur.a.arora@xxxxxxxxxx>
---
arch/x86/xen/Makefile | 1 +
arch/x86/xen/enlighten_hvm.c | 13 +++++
arch/x86/xen/enlighten_pv.c | 16 ++++++
arch/x86/xen/enlighten_pvh.c | 12 +++++
arch/x86/xen/xenhost.c | 75 ++++++++++++++++++++++++++++
include/xen/xen.h | 3 ++
include/xen/xenhost.h | 95 ++++++++++++++++++++++++++++++++++++
7 files changed, 215 insertions(+)
create mode 100644 arch/x86/xen/xenhost.c
create mode 100644 include/xen/xenhost.h
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 084de77a109e..564b4dddbc15 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -18,6 +18,7 @@ obj-y += mmu.o
obj-y += time.o
obj-y += grant-table.o
obj-y += suspend.o
+obj-y += xenhost.o
obj-$(CONFIG_XEN_PVHVM) += enlighten_hvm.o
obj-$(CONFIG_XEN_PVHVM) += mmu_hvm.o
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 0e75642d42a3..100452f4f44c 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -5,6 +5,7 @@
#include <linux/kexec.h>
#include <linux/memblock.h>
+#include <xen/xenhost.h>
#include <xen/features.h>
#include <xen/events.h>
#include <xen/interface/memory.h>
@@ -82,6 +83,12 @@ static void __init xen_hvm_init_mem_mapping(void)
xen_vcpu_info_reset(0);
}
+xenhost_ops_t xh_hvm_ops = {
+};
+
+xenhost_ops_t xh_hvm_nested_ops = {
+};
+
static void __init init_hvm_pv_info(void)
{
int major, minor;
@@ -179,6 +186,12 @@ static void __init xen_hvm_guest_init(void)
{
if (xen_pv_domain())
return;
+ /*
+ * We need only xenhost_r1 for HVM guests since they cannot be
+ * driver domain (?) or dom0.
I think even HVM guests could (in theory) be driver domains.
+ */
+ if (!xen_pvh_domain())
+ xenhost_register(xenhost_r1, &xh_hvm_ops);
init_hvm_pv_info();
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493e139a..bb6e811c1525 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -36,6 +36,7 @@
#include <xen/xen.h>
#include <xen/events.h>
+#include <xen/xenhost.h>
#include <xen/interface/xen.h>
#include <xen/interface/version.h>
#include <xen/interface/physdev.h>
@@ -1188,6 +1189,12 @@ static void __init
xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
}
+xenhost_ops_t xh_pv_ops = {
+};
+
+xenhost_ops_t xh_pv_nested_ops = {
+};
+
/* First C function to be called on Xen boot */
asmlinkage __visible void __init xen_start_kernel(void)
{
@@ -1198,6 +1205,15 @@ asmlinkage __visible void __init
xen_start_kernel(void)
if (!xen_start_info)
return;
+ xenhost_register(xenhost_r1, &xh_pv_ops);
+
+ /*
+ * Detect in some implementation defined manner whether this is
+ * nested or not.
+ */
+ if (xen_driver_domain() && xen_nested())
+ xenhost_register(xenhost_r2, &xh_pv_nested_ops);
I don't think a driver domain other than dom0 "knows" this in the
beginning. It will need to register xenhost_r2
Right. No point in needlessly registrating as xenhost_r2 without
needing to handle any xenhost_r2 devices.
in case it learns about a pv device from L0 hypervisor.
What's the mechanism you are thinking of, for this?
I'm guessing this PV device notification could arrive at an
arbitrary point in time after the system has booted.
I'm not sure yet how this should be handled.
Maybe an easy solution would be the presence of a Xen PCI device
passed through from L1 hypervisor to L1 dom0. OTOH this would
preclude nested Xen for L1 hypervisor running in PVH mode. And for
L1 driver domains this would need either a shared PCI device or
multiple Xen PCI devices or something new.
There is a design session planned for this topic at the Xen developer
summit in July.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
