[PATCH v2 00/23] Vixen: A PV-in-HVM shim

[PATCH v2 00/23] Vixen: A PV-in-HVM shim

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
appears to be very difficult to isolate the hypervisor's page tables
from PV domUs while maintaining ABI compatibility.  Instead of trying
to make a KPTI-like approach work for Xen PV, it seems reasonable to
run a copy of Xen within an HVM (or PVH) domU to provide backwards
compatibility with guests as mentioned in XSA-254 [1].

This patch series adds a new mode to Xen called Vixen (Virtualized
Xen) which provides a PV-compatible interface while gaining
CVE-2017-5754 protection for the host provided by hardware
virtualization.  Vixen supports running a single unprivileged PV
domain (a dom1) that is constructed by the dom0 domain builder.

Please note the Xen page table configuration fundamental to the
current PV ABI makes it impossible for an operating system to mitigate
CVE-2017-5754 through mechanisms like Kernel Page Table Isolation
(KPTI).  In order for an operating system to mitigate CVE-2017-5754 it
must run directly in a HVM or PVH domU.

This series is very similar to the PVH series posted by Wei and we
have been discussing how to merge efforts.  We were hoping to have
more time to work this out.  I am posting this because I'm fairly
confident that this series is complete (all PV instances in EC2 are
using this) and others might find it useful.  I also wanted to have
more of a discussion about the best way to merge and some of the
differences in designs.

This series is also available at:

 git clone https://github.com/aliguori/xen.git vixen-upstream-v2

Changelog:
v1 -> v2
 - fix ARM build
 - add vixen_domid command line parameter
 - make version pass through optional
 - pull in p2m mapping fix from sidewinder
 - panic if dom0_construct_pv fails
 - #defines for the vendor/device id of platform device
 - coding style for event channel polling
 - reserve even more in the e820 table based on hvm_info_table
 - moved shared info to special page range
 - make grant table frames come from special page range
 - refactor grant tables to use single dispatch function

Not in this version:
 - Avoiding vixen domain == hardware domain

Regards,

Anthony Liguori

[1] https://xenbits.xen.org/xsa/advisory-254.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 01/23] ---- x86/Kconfig: Options for Xen and PVH support

[Anthony Liguori]

From: Andrew Cooper <andrew.cooper3@citrix.com>

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/Kconfig | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7c45829..07530bf 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -117,6 +117,23 @@ config TBOOT
 	  Technology (TXT)
 
 	  If unsure, say Y.
+
+config XEN_GUEST
+	def_bool y
+	prompt "Xen Guest"
+	---help---
+	  Support for Xen detecting when it is running under Xen.
+
+	  If unsure, say Y.
+
+config PVH_GUEST
+	def_bool n
+	prompt "PVH Guest"
+	depends on XEN_GUEST
+	---help---
+	  Support booting using the PVH ABI.
+
+	  If unsure, say N.
 endmenu
 
 source "common/Kconfig"
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 02/23] x86/entry: Probe for Xen early during boot

[Anthony Liguori]

From: Andrew Cooper <andrew.cooper3@citrix.com>

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
v1 -> v2
 - ARM stubs
---
 xen/arch/x86/Makefile           |  1 +
 xen/arch/x86/guest/Makefile     |  1 +
 xen/arch/x86/guest/xen.c        | 75 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/setup.c            |  4 +++
 xen/include/asm-arm/guest.h     | 22 ++++++++++++
 xen/include/asm-x86/guest.h     | 34 +++++++++++++++++++
 xen/include/asm-x86/guest/xen.h | 47 ++++++++++++++++++++++++++
 7 files changed, 184 insertions(+)
 create mode 100644 xen/arch/x86/guest/Makefile
 create mode 100644 xen/arch/x86/guest/xen.c
 create mode 100644 xen/include/asm-arm/guest.h
 create mode 100644 xen/include/asm-x86/guest.h
 create mode 100644 xen/include/asm-x86/guest/xen.h

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d5d58a2..c1977d1 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,6 +1,7 @@
 subdir-y += acpi
 subdir-y += cpu
 subdir-y += genapic
+subdir-$(CONFIG_XEN_GUEST) += guest
 subdir-$(CONFIG_HVM) += hvm
 subdir-y += mm
 subdir-$(CONFIG_XENOPROF) += oprofile
diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
new file mode 100644
index 0000000..7f67396
--- /dev/null
+++ b/xen/arch/x86/guest/Makefile
@@ -0,0 +1 @@
+obj-y += xen.o
diff --git a/xen/arch/x86/guest/xen.c b/xen/arch/x86/guest/xen.c
new file mode 100644
index 0000000..9446a46
--- /dev/null
+++ b/xen/arch/x86/guest/xen.c
@@ -0,0 +1,75 @@
+/******************************************************************************
+ * arch/x86/guest/xen.c
+ *
+ * Support for detecting and running under Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (c) 2017 Citrix Systems Ltd.
+ */
+#include <xen/init.h>
+#include <xen/types.h>
+
+#include <asm/guest.h>
+#include <asm/processor.h>
+
+#include <public/arch-x86/cpuid.h>
+
+bool xen_guest;
+
+static uint32_t xen_cpuid_base;
+
+static void __init find_xen_leaves(void)
+{
+    uint32_t eax, ebx, ecx, edx, base;
+
+    for ( base = XEN_CPUID_FIRST_LEAF;
+          base < XEN_CPUID_FIRST_LEAF + 0x10000; base += 0x100 )
+    {
+        cpuid(base, &eax, &ebx, &ecx, &edx);
+
+        if ( (ebx == XEN_CPUID_SIGNATURE_EBX) &&
+             (ecx == XEN_CPUID_SIGNATURE_ECX) &&
+             (edx == XEN_CPUID_SIGNATURE_EDX) &&
+             ((eax - base) >= 2) )
+        {
+            xen_cpuid_base = base;
+            break;
+        }
+    }
+}
+
+void __init probe_hypervisor(void)
+{
+    /* Too early to use cpu_has_hypervisor */
+    if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
+        return;
+
+    find_xen_leaves();
+
+    if ( !xen_cpuid_base )
+        return;
+
+    xen_guest = true;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2e10c6b..7627c3f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -51,6 +51,8 @@
 #include <asm/alternative.h>
 #include <asm/mc146818rtc.h>
 #include <asm/cpuid.h>
+#include <asm/guest.h>
+#include <public/arch-x86/cpuid.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
@@ -704,6 +706,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
      * allocing any xenheap structures wanted in lower memory. */
     kexec_early_calculations();
 
+    probe_hypervisor();
+
     parse_video_info();
 
     rdmsrl(MSR_EFER, this_cpu(efer));
diff --git a/xen/include/asm-arm/guest.h b/xen/include/asm-arm/guest.h
new file mode 100644
index 0000000..4d143d7
--- /dev/null
+++ b/xen/include/asm-arm/guest.h
@@ -0,0 +1,22 @@
+/******************************************************************************
+ * include/asm-x86/guest.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright 2018 Amazon.com, Inc. or its affiliates.
+ */
+
+#ifndef __ARM_GUEST_H__
+#define __ARM_GUEST_H__
+
+#endif
diff --git a/xen/include/asm-x86/guest.h b/xen/include/asm-x86/guest.h
new file mode 100644
index 0000000..eb08434
--- /dev/null
+++ b/xen/include/asm-x86/guest.h
@@ -0,0 +1,34 @@
+/******************************************************************************
+ * asm-x86/guest.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (c) 2017 Citrix Systems Ltd.
+ */
+
+#ifndef __X86_GUEST_H__
+#define __X86_GUEST_H__
+
+#include <asm/guest/xen.h>
+
+#endif /* __X86_GUEST_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h
new file mode 100644
index 0000000..97a7c8d
--- /dev/null
+++ b/xen/include/asm-x86/guest/xen.h
@@ -0,0 +1,47 @@
+/******************************************************************************
+ * asm-x86/guest/xen.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (c) 2017 Citrix Systems Ltd.
+ */
+
+#ifndef __X86_GUEST_XEN_H__
+#define __X86_GUEST_XEN_H__
+
+#include <xen/types.h>
+
+#ifdef CONFIG_XEN_GUEST
+
+extern bool xen_guest;
+
+void probe_hypervisor(void);
+
+#else
+
+#define xen_guest 0
+
+static inline void probe_hypervisor(void) {};
+
+#endif /* CONFIG_XEN_GUEST */
+#endif /* __X86_GUEST_XEN_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 03/23] x86/guest: Hypercall support

[Anthony Liguori]

From: Andrew Cooper <andrew.cooper3@citrix.com>

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/guest/Makefile           |  1 +
 xen/arch/x86/guest/hypercall_page.S   | 79 ++++++++++++++++++++++++++++++
 xen/arch/x86/guest/xen.c              |  5 ++
 xen/arch/x86/xen.lds.S                |  1 +
 xen/include/asm-x86/guest.h           |  1 +
 xen/include/asm-x86/guest/hypercall.h | 92 +++++++++++++++++++++++++++++++++++
 6 files changed, 179 insertions(+)
 create mode 100644 xen/arch/x86/guest/hypercall_page.S
 create mode 100644 xen/include/asm-x86/guest/hypercall.h

diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
index 7f67396..c5d5188 100644
--- a/xen/arch/x86/guest/Makefile
+++ b/xen/arch/x86/guest/Makefile
@@ -1 +1,2 @@
+obj-y += hypercall_page.o
 obj-y += xen.o
diff --git a/xen/arch/x86/guest/hypercall_page.S b/xen/arch/x86/guest/hypercall_page.S
new file mode 100644
index 0000000..fdd2e72
--- /dev/null
+++ b/xen/arch/x86/guest/hypercall_page.S
@@ -0,0 +1,79 @@
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+        .section ".text.page_aligned", "ax", @progbits
+        .p2align PAGE_SHIFT
+
+GLOBAL(hypercall_page)
+         /* Poisoned with `ret` for safety before hypercalls are set up. */
+        .fill PAGE_SIZE, 1, 0xc3
+        .type hypercall_page, STT_OBJECT
+        .size hypercall_page, PAGE_SIZE
+
+/*
+ * Identify a specific hypercall in the hypercall page
+ * @param name Hypercall name.
+ */
+#define DECLARE_HYPERCALL(name)                                                 \
+        .globl HYPERCALL_ ## name;                                              \
+        .set   HYPERCALL_ ## name, hypercall_page + __HYPERVISOR_ ## name * 32; \
+        .type  HYPERCALL_ ## name, STT_FUNC;                                    \
+        .size  HYPERCALL_ ## name, 32
+
+DECLARE_HYPERCALL(set_trap_table)
+DECLARE_HYPERCALL(mmu_update)
+DECLARE_HYPERCALL(set_gdt)
+DECLARE_HYPERCALL(stack_switch)
+DECLARE_HYPERCALL(set_callbacks)
+DECLARE_HYPERCALL(fpu_taskswitch)
+DECLARE_HYPERCALL(sched_op_compat)
+DECLARE_HYPERCALL(platform_op)
+DECLARE_HYPERCALL(set_debugreg)
+DECLARE_HYPERCALL(get_debugreg)
+DECLARE_HYPERCALL(update_descriptor)
+DECLARE_HYPERCALL(memory_op)
+DECLARE_HYPERCALL(multicall)
+DECLARE_HYPERCALL(update_va_mapping)
+DECLARE_HYPERCALL(set_timer_op)
+DECLARE_HYPERCALL(event_channel_op_compat)
+DECLARE_HYPERCALL(xen_version)
+DECLARE_HYPERCALL(console_io)
+DECLARE_HYPERCALL(physdev_op_compat)
+DECLARE_HYPERCALL(grant_table_op)
+DECLARE_HYPERCALL(vm_assist)
+DECLARE_HYPERCALL(update_va_mapping_otherdomain)
+DECLARE_HYPERCALL(iret)
+DECLARE_HYPERCALL(vcpu_op)
+DECLARE_HYPERCALL(set_segment_base)
+DECLARE_HYPERCALL(mmuext_op)
+DECLARE_HYPERCALL(xsm_op)
+DECLARE_HYPERCALL(nmi_op)
+DECLARE_HYPERCALL(sched_op)
+DECLARE_HYPERCALL(callback_op)
+DECLARE_HYPERCALL(xenoprof_op)
+DECLARE_HYPERCALL(event_channel_op)
+DECLARE_HYPERCALL(physdev_op)
+DECLARE_HYPERCALL(hvm_op)
+DECLARE_HYPERCALL(sysctl)
+DECLARE_HYPERCALL(domctl)
+DECLARE_HYPERCALL(kexec_op)
+DECLARE_HYPERCALL(tmem_op)
+DECLARE_HYPERCALL(xc_reserved_op)
+DECLARE_HYPERCALL(xenpmu_op)
+
+DECLARE_HYPERCALL(arch_0)
+DECLARE_HYPERCALL(arch_1)
+DECLARE_HYPERCALL(arch_2)
+DECLARE_HYPERCALL(arch_3)
+DECLARE_HYPERCALL(arch_4)
+DECLARE_HYPERCALL(arch_5)
+DECLARE_HYPERCALL(arch_6)
+DECLARE_HYPERCALL(arch_7)
+
+/*
+ * Local variables:
+ * tab-width: 8
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/guest/xen.c b/xen/arch/x86/guest/xen.c
index 9446a46..c5b4341 100644
--- a/xen/arch/x86/guest/xen.c
+++ b/xen/arch/x86/guest/xen.c
@@ -22,6 +22,7 @@
 #include <xen/types.h>
 
 #include <asm/guest.h>
+#include <asm/msr.h>
 #include <asm/processor.h>
 
 #include <public/arch-x86/cpuid.h>
@@ -29,6 +30,7 @@
 bool xen_guest;
 
 static uint32_t xen_cpuid_base;
+extern char hypercall_page[];
 
 static void __init find_xen_leaves(void)
 {
@@ -61,6 +63,9 @@ void __init probe_hypervisor(void)
     if ( !xen_cpuid_base )
         return;
 
+    /* Fill the hypercall page. */
+    wrmsrl(cpuid_ebx(xen_cpuid_base + 2), __pa(hypercall_page));
+
     xen_guest = true;
 }
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d5e8821..dd0e1c5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -59,6 +59,7 @@ SECTIONS
   .text : {
         _stext = .;            /* Text and read-only data */
        *(.text)
+       *(.text.page_aligned)
        *(.text.cold)
        *(.text.unlikely)
        *(.fixup)
diff --git a/xen/include/asm-x86/guest.h b/xen/include/asm-x86/guest.h
index eb08434..70250b7 100644
--- a/xen/include/asm-x86/guest.h
+++ b/xen/include/asm-x86/guest.h
@@ -19,6 +19,7 @@
 #ifndef __X86_GUEST_H__
 #define __X86_GUEST_H__
 
+#include <asm/guest/hypercall.h>
 #include <asm/guest/xen.h>
 
 #endif /* __X86_GUEST_H__ */
diff --git a/xen/include/asm-x86/guest/hypercall.h b/xen/include/asm-x86/guest/hypercall.h
new file mode 100644
index 0000000..c460f59
--- /dev/null
+++ b/xen/include/asm-x86/guest/hypercall.h
@@ -0,0 +1,92 @@
+/******************************************************************************
+ * asm-x86/guest/hypercall.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (c) 2017 Citrix Systems Ltd.
+ */
+
+#ifndef __X86_XEN_HYPERCALL_H__
+#define __X86_XEN_HYPERCALL_H__
+
+#ifdef CONFIG_XEN_GUEST
+
+/*
+ * Hypercall primatives for 64bit
+ *
+ * Inputs: %rdi, %rsi, %rdx, %r10, %r8, %r9 (arguments 1-6)
+ */
+
+#define _hypercall64_1(type, hcall, a1)                                 \
+    ({                                                                  \
+        long res, tmp;                                                  \
+        asm volatile (                                                  \
+            "call hypercall_page + %c[offset]"                          \
+            : "=a" (res), "=D" (tmp)                                    \
+            : [offset] "i" (hcall * 32),                                \
+              "1" ((long)(a1))                                          \
+            : "memory" );                                               \
+        (type)res;                                                      \
+    })
+
+#define _hypercall64_2(type, hcall, a1, a2)                             \
+    ({                                                                  \
+        long res, tmp;                                                  \
+        asm volatile (                                                  \
+            "call hypercall_page + %c[offset]"                          \
+            : "=a" (res), "=D" (tmp), "=S" (tmp)                        \
+            : [offset] "i" (hcall * 32),                                \
+              "1" ((long)(a1)), "2" ((long)(a2))                        \
+            : "memory" );                                               \
+        (type)res;                                                      \
+    })
+
+#define _hypercall64_3(type, hcall, a1, a2, a3)                         \
+    ({                                                                  \
+        long res, tmp;                                                  \
+        asm volatile (                                                  \
+            "call hypercall_page + %c[offset]"                          \
+            : "=a" (res), "=D" (tmp), "=S" (tmp), "=d" (tmp)            \
+            : [offset] "i" (hcall * 32),                                \
+              "1" ((long)(a1)), "2" ((long)(a2)), "3" ((long)(a3))      \
+            : "memory" );                                               \
+        (type)res;                                                      \
+    })
+
+#define _hypercall64_4(type, hcall, a1, a2, a3, a4)                     \
+    ({                                                                  \
+        long res, tmp;                                                  \
+        register long _a4 asm ("r10") = ((long)(a4));                   \
+        asm volatile (                                                  \
+            "call hypercall_page + %c[offset]"                          \
+            : "=a" (res), "=D" (tmp), "=S" (tmp), "=d" (tmp),           \
+              "=&r" (tmp)                                               \
+            : [offset] "i" (hcall * 32),                                \
+              "1" ((long)(a1)), "2" ((long)(a2)), "3" ((long)(a3)),     \
+              "4" (_a4)                                                 \
+            : "memory" );                                               \
+        (type)res;                                                      \
+    })
+
+#endif /* CONFIG_XEN_GUEST */
+#endif /* __X86_XEN_HYPERCALL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Anthony Liguori]

From: Jan H. Schönherr <jschoenh@amazon.de>

Intel says for CPUID leaf 0Bh:

  "Software must not use EBX[15:0] to enumerate processor
   topology of the system. This value in this field
   (EBX[15:0]) is only intended for display/diagnostic
   purposes. The actual number of logical processors
   available to BIOS/OS/Applications may be different from
   the value of EBX[15:0], depending on software and platform
   hardware configurations."

And yet, we're using them to derive the number cores in a package
and the number of siblings in a core.

Derive the number of siblings and cores from EAX instead, which is
intended for that.

Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
---
 xen/arch/x86/cpu/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index e9588b3..22f392f 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
 	initial_apicid = edx;
 
 	/* Populate HT related information from sub-leaf level 0 */
-	core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
 	core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
+	core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
 
 	sub_index = 1;
 	do {
@@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
 
 		/* Check for the Core type in the implemented sub leaves */
 		if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
-			core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
 			core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
+			core_level_siblings = 1 << core_plus_mask_width;
 			break;
 		}
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Andrew Cooper]

On 07/01/18 20:28, Anthony Liguori wrote:
> From: Jan H. Schönherr <jschoenh@amazon.de>
>
> Intel says for CPUID leaf 0Bh:
>
>   "Software must not use EBX[15:0] to enumerate processor
>    topology of the system. This value in this field
>    (EBX[15:0]) is only intended for display/diagnostic
>    purposes. The actual number of logical processors
>    available to BIOS/OS/Applications may be different from
>    the value of EBX[15:0], depending on software and platform
>    hardware configurations."
>
> And yet, we're using them to derive the number cores in a package
> and the number of siblings in a core.
>
> Derive the number of siblings and cores from EAX instead, which is
> intended for that.
>
> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>, although I'll
fix the 1 to 1u on commit.

> ---
>  xen/arch/x86/cpu/common.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index e9588b3..22f392f 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>  	initial_apicid = edx;
>  
>  	/* Populate HT related information from sub-leaf level 0 */
> -	core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>  	core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> +	core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>  
>  	sub_index = 1;
>  	do {
> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>  
>  		/* Check for the Core type in the implemented sub leaves */
>  		if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
> -			core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>  			core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> +			core_level_siblings = 1 << core_plus_mask_width;
>  			break;
>  		}
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Simon Gaiser]

[-- Attachment #1.1: Type: text/plain, Size: 2600 bytes --]

Anthony Liguori:
> From: Jan H. Schönherr <jschoenh@amazon.de>
> 
> Intel says for CPUID leaf 0Bh:
> 
>   "Software must not use EBX[15:0] to enumerate processor
>    topology of the system. This value in this field
>    (EBX[15:0]) is only intended for display/diagnostic
>    purposes. The actual number of logical processors
>    available to BIOS/OS/Applications may be different from
>    the value of EBX[15:0], depending on software and platform
>    hardware configurations."
> 
> And yet, we're using them to derive the number cores in a package
> and the number of siblings in a core.
> 
> Derive the number of siblings and cores from EAX instead, which is
> intended for that.
> 
> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
> ---
>  xen/arch/x86/cpu/common.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index e9588b3..22f392f 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>  	initial_apicid = edx;
>  
>  	/* Populate HT related information from sub-leaf level 0 */
> -	core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>  	core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> +	core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>  
>  	sub_index = 1;
>  	do {
> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>  
>  		/* Check for the Core type in the implemented sub leaves */
>  		if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
> -			core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>  			core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> +			core_level_siblings = 1 << core_plus_mask_width;


On the i5-1135G7 (4 cores with each 2 threads) I'm currently testing on
I noticed that this changes leads to core_level_siblings == 16 and
therefore x86_max_cores == 8. If read from ebx like before this change
and what Linux is still doing [1] it reads core_level_siblings == 8 (as
expected?).

What's the expected semantic here? If it's to derive the actual number
of siblings (and therefore cores) in a package as the commit message
suggest, the new code can't work even ignoring the example from my test
system. It will always produce powers of 2, so can't get it right on a
system with, say, 6 cores.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/topology.c?h=v6.4#n126

>  			break;
>  		}
>  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Xen-devel] [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Jan Beulich]

On 07.08.2023 10:18, Simon Gaiser wrote:
> Anthony Liguori:
>> From: Jan H. Schönherr <jschoenh@amazon.de>
>>
>> Intel says for CPUID leaf 0Bh:
>>
>>   "Software must not use EBX[15:0] to enumerate processor
>>    topology of the system. This value in this field
>>    (EBX[15:0]) is only intended for display/diagnostic
>>    purposes. The actual number of logical processors
>>    available to BIOS/OS/Applications may be different from
>>    the value of EBX[15:0], depending on software and platform
>>    hardware configurations."
>>
>> And yet, we're using them to derive the number cores in a package
>> and the number of siblings in a core.
>>
>> Derive the number of siblings and cores from EAX instead, which is
>> intended for that.
>>
>> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
>> ---
>>  xen/arch/x86/cpu/common.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>> index e9588b3..22f392f 100644
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>  	initial_apicid = edx;
>>  
>>  	/* Populate HT related information from sub-leaf level 0 */
>> -	core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>  	core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>> +	core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>>  
>>  	sub_index = 1;
>>  	do {
>> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>  
>>  		/* Check for the Core type in the implemented sub leaves */
>>  		if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
>> -			core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>  			core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>> +			core_level_siblings = 1 << core_plus_mask_width;
> 
> 
> On the i5-1135G7 (4 cores with each 2 threads) I'm currently testing on
> I noticed that this changes leads to core_level_siblings == 16 and
> therefore x86_max_cores == 8. If read from ebx like before this change
> and what Linux is still doing [1] it reads core_level_siblings == 8 (as
> expected?).
> 
> What's the expected semantic here? If it's to derive the actual number
> of siblings (and therefore cores) in a package as the commit message
> suggest, the new code can't work even ignoring the example from my test
> system. It will always produce powers of 2, so can't get it right on a
> system with, say, 6 cores.

The only use of the variable in question is in this statement:

	c->x86_max_cores = (core_level_siblings / c->x86_num_siblings);

Note the "max" in the name. This is how many _could_ be there, not how
many _are_ there, aiui.

Jan

Re: [Xen-devel] [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Simon Gaiser]

[-- Attachment #1.1: Type: text/plain, Size: 3755 bytes --]

Jan Beulich:
> On 07.08.2023 10:18, Simon Gaiser wrote:
>> Anthony Liguori:
>>> From: Jan H. Schönherr <jschoenh@amazon.de>
>>>
>>> Intel says for CPUID leaf 0Bh:
>>>
>>>   "Software must not use EBX[15:0] to enumerate processor
>>>    topology of the system. This value in this field
>>>    (EBX[15:0]) is only intended for display/diagnostic
>>>    purposes. The actual number of logical processors
>>>    available to BIOS/OS/Applications may be different from
>>>    the value of EBX[15:0], depending on software and platform
>>>    hardware configurations."
>>>
>>> And yet, we're using them to derive the number cores in a package
>>> and the number of siblings in a core.
>>>
>>> Derive the number of siblings and cores from EAX instead, which is
>>> intended for that.
>>>
>>> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
>>> ---
>>>  xen/arch/x86/cpu/common.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>> index e9588b3..22f392f 100644
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>>     initial_apicid = edx;
>>>  
>>>     /* Populate HT related information from sub-leaf level 0 */
>>> -   core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>>     core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>>> +   core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>>>  
>>>     sub_index = 1;
>>>     do {
>>> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>>  
>>>             /* Check for the Core type in the implemented sub leaves */
>>>             if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
>>> -                   core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>>                     core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>>> +                   core_level_siblings = 1 << core_plus_mask_width;
>>
>>
>> On the i5-1135G7 (4 cores with each 2 threads) I'm currently testing on
>> I noticed that this changes leads to core_level_siblings == 16 and
>> therefore x86_max_cores == 8. If read from ebx like before this change
>> and what Linux is still doing [1] it reads core_level_siblings == 8 (as
>> expected?).
>>
>> What's the expected semantic here? If it's to derive the actual number
>> of siblings (and therefore cores) in a package as the commit message
>> suggest, the new code can't work even ignoring the example from my test
>> system. It will always produce powers of 2, so can't get it right on a
>> system with, say, 6 cores.
> 
> The only use of the variable in question is in this statement:
> 
>       c->x86_max_cores = (core_level_siblings / c->x86_num_siblings);
> 
> Note the "max" in the name. This is how many _could_ be there, not how
> many _are_ there, aiui.

I'm indeed not quite sure on the intended semantic, hence the question
(although it's not clear to me what case that "could" would cover here).

It doesn't have to be identical but Linux says for it's version of the
variable:

    The number of cores in a package. This information is retrieved via
    CPUID.

And if I look at it's usage in set_nr_sockets in Xen:

    nr_sockets = last_physid(phys_cpu_present_map)
                 / boot_cpu_data.x86_max_cores
                 / boot_cpu_data.x86_num_siblings + 1;

It seems to be also be used in this meaning. At least on my test system
I get last_physid == 7 (as I would have expected for 8 logical cpus). So
dividing this by the 4 (number of cores) and 2 (threads per core) is
what I think was intended here.

Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Xen-devel] [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Jan Beulich]

On 07.08.2023 11:58, Simon Gaiser wrote:
> Jan Beulich:
>> On 07.08.2023 10:18, Simon Gaiser wrote:
>>> Anthony Liguori:
>>>> From: Jan H. Schönherr <jschoenh@amazon.de>
>>>>
>>>> Intel says for CPUID leaf 0Bh:
>>>>
>>>>   "Software must not use EBX[15:0] to enumerate processor
>>>>    topology of the system. This value in this field
>>>>    (EBX[15:0]) is only intended for display/diagnostic
>>>>    purposes. The actual number of logical processors
>>>>    available to BIOS/OS/Applications may be different from
>>>>    the value of EBX[15:0], depending on software and platform
>>>>    hardware configurations."
>>>>
>>>> And yet, we're using them to derive the number cores in a package
>>>> and the number of siblings in a core.
>>>>
>>>> Derive the number of siblings and cores from EAX instead, which is
>>>> intended for that.
>>>>
>>>> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
>>>> ---
>>>>  xen/arch/x86/cpu/common.c | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>>> index e9588b3..22f392f 100644
>>>> --- a/xen/arch/x86/cpu/common.c
>>>> +++ b/xen/arch/x86/cpu/common.c
>>>> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>>>     initial_apicid = edx;
>>>>  
>>>>     /* Populate HT related information from sub-leaf level 0 */
>>>> -   core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>>>     core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>>>> +   core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>>>>  
>>>>     sub_index = 1;
>>>>     do {
>>>> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>>>  
>>>>             /* Check for the Core type in the implemented sub leaves */
>>>>             if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
>>>> -                   core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>>>                     core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>>>> +                   core_level_siblings = 1 << core_plus_mask_width;
>>>
>>>
>>> On the i5-1135G7 (4 cores with each 2 threads) I'm currently testing on
>>> I noticed that this changes leads to core_level_siblings == 16 and
>>> therefore x86_max_cores == 8. If read from ebx like before this change
>>> and what Linux is still doing [1] it reads core_level_siblings == 8 (as
>>> expected?).
>>>
>>> What's the expected semantic here? If it's to derive the actual number
>>> of siblings (and therefore cores) in a package as the commit message
>>> suggest, the new code can't work even ignoring the example from my test
>>> system. It will always produce powers of 2, so can't get it right on a
>>> system with, say, 6 cores.
>>
>> The only use of the variable in question is in this statement:
>>
>>       c->x86_max_cores = (core_level_siblings / c->x86_num_siblings);
>>
>> Note the "max" in the name. This is how many _could_ be there, not how
>> many _are_ there, aiui.
> 
> I'm indeed not quite sure on the intended semantic, hence the question
> (although it's not clear to me what case that "could" would cover here).

"Could" covers for a number of reasons why APIC IDs may not be contiguous.
Consider a 6-code system: The APIC IDs need to cover for at least 8 there.

> It doesn't have to be identical but Linux says for it's version of the
> variable:
> 
>     The number of cores in a package. This information is retrieved via
>     CPUID.
> 
> And if I look at it's usage in set_nr_sockets in Xen:
> 
>     nr_sockets = last_physid(phys_cpu_present_map)
>                  / boot_cpu_data.x86_max_cores
>                  / boot_cpu_data.x86_num_siblings + 1;

This validly uses the field in the "max" sense, not in the "actual" one.

> It seems to be also be used in this meaning. At least on my test system
> I get last_physid == 7 (as I would have expected for 8 logical cpus). So
> dividing this by the 4 (number of cores) and 2 (threads per core) is
> what I think was intended here.

Would you mind providing raw data from your system: Both the raw CPUID
output for the leaf/leaves of interest here and the APIC IDs of all
threads?

Jan

Re: [Xen-devel] [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Simon Gaiser]

[-- Attachment #1.1.1: Type: text/plain, Size: 12646 bytes --]

Jan Beulich:
> On 07.08.2023 11:58, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 07.08.2023 10:18, Simon Gaiser wrote:
>>>> Anthony Liguori:
>>>>> From: Jan H. Schönherr <jschoenh@amazon.de>
>>>>>
>>>>> Intel says for CPUID leaf 0Bh:
>>>>>
>>>>>   "Software must not use EBX[15:0] to enumerate processor
>>>>>    topology of the system. This value in this field
>>>>>    (EBX[15:0]) is only intended for display/diagnostic
>>>>>    purposes. The actual number of logical processors
>>>>>    available to BIOS/OS/Applications may be different from
>>>>>    the value of EBX[15:0], depending on software and platform
>>>>>    hardware configurations."
>>>>>
>>>>> And yet, we're using them to derive the number cores in a package
>>>>> and the number of siblings in a core.
>>>>>
>>>>> Derive the number of siblings and cores from EAX instead, which is
>>>>> intended for that.
>>>>>
>>>>> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
>>>>> ---
>>>>>  xen/arch/x86/cpu/common.c | 4 ++--
>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>>>> index e9588b3..22f392f 100644
>>>>> --- a/xen/arch/x86/cpu/common.c
>>>>> +++ b/xen/arch/x86/cpu/common.c
>>>>> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>>>>     initial_apicid = edx;
>>>>>  
>>>>>     /* Populate HT related information from sub-leaf level 0 */
>>>>> -   core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>>>>     core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>>>>> +   core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>>>>>  
>>>>>     sub_index = 1;
>>>>>     do {
>>>>> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>>>>  
>>>>>             /* Check for the Core type in the implemented sub leaves */
>>>>>             if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
>>>>> -                   core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>>>>                     core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>>>>> +                   core_level_siblings = 1 << core_plus_mask_width;
>>>>
>>>>
>>>> On the i5-1135G7 (4 cores with each 2 threads) I'm currently testing on
>>>> I noticed that this changes leads to core_level_siblings == 16 and
>>>> therefore x86_max_cores == 8. If read from ebx like before this change
>>>> and what Linux is still doing [1] it reads core_level_siblings == 8 (as
>>>> expected?).
>>>>
>>>> What's the expected semantic here? If it's to derive the actual number
>>>> of siblings (and therefore cores) in a package as the commit message
>>>> suggest, the new code can't work even ignoring the example from my test
>>>> system. It will always produce powers of 2, so can't get it right on a
>>>> system with, say, 6 cores.
>>>
>>> The only use of the variable in question is in this statement:
>>>
>>>       c->x86_max_cores = (core_level_siblings / c->x86_num_siblings);
>>>
>>> Note the "max" in the name. This is how many _could_ be there, not how
>>> many _are_ there, aiui.
>>
>> I'm indeed not quite sure on the intended semantic, hence the question
>> (although it's not clear to me what case that "could" would cover here).
> 
> "Could" covers for a number of reasons why APIC IDs may not be contiguous.
> Consider a 6-code system: The APIC IDs need to cover for at least 8 there.
> 
>> It doesn't have to be identical but Linux says for it's version of the
>> variable:
>>
>>     The number of cores in a package. This information is retrieved via
>>     CPUID.
>>
>> And if I look at it's usage in set_nr_sockets in Xen:
>>
>>     nr_sockets = last_physid(phys_cpu_present_map)
>>                  / boot_cpu_data.x86_max_cores
>>                  / boot_cpu_data.x86_num_siblings + 1;
> 
> This validly uses the field in the "max" sense, not in the "actual" one.

I see, both cases cover APIC IDs not just numbers of logical CPUs.
Thanks for the explanation and the pointer from Andrew in his response.

I just had noticed the, to me, unexpected value, while debugging
something. But based on this explanation things are actually working
as intended here. (The actual problem I was looking for it turned out
to be [1].)

[1]: https://lore.kernel.org/xen-devel/7f158a54548456daba9f2e105d099d2e5e2c2f38.1691399031.git.simon@invisiblethingslab.com/

>> It seems to be also be used in this meaning. At least on my test system
>> I get last_physid == 7 (as I would have expected for 8 logical cpus). So
>> dividing this by the 4 (number of cores) and 2 (threads per core) is
>> what I think was intended here.
> 
> Would you mind providing raw data from your system: Both the raw CPUID
> output for the leaf/leaves of interest here and the APIC IDs of all
> threads?

Sure:

From attached patch:

(XEN) dbg smp_processor_id() = 0
(XEN) dbg get_apic_id() = 0
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0

(XEN) dbg smp_processor_id() = 1
(XEN) dbg get_apic_id() = 1
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x1
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x1

(XEN) dbg smp_processor_id() = 2
(XEN) dbg get_apic_id() = 2
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x2
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x2

(XEN) dbg smp_processor_id() = 3
(XEN) dbg get_apic_id() = 3
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x3
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x3

(XEN) dbg smp_processor_id() = 4
(XEN) dbg get_apic_id() = 4
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x4
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x4

(XEN) dbg smp_processor_id() = 5
(XEN) dbg get_apic_id() = 5
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x5
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x5

(XEN) dbg smp_processor_id() = 6
(XEN) dbg get_apic_id() = 6
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x6
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x6

(XEN) dbg smp_processor_id() = 7
(XEN) dbg get_apic_id() = 7
(XEN) dbg cpuid_count(0xb, SMT_LEVEL) = 0x1, 0x2, 0x100, 0x7
(XEN) dbg cpuid_count(0xb, 0x1) = 0x4, 0x8, 0x201, 0x7

From the MADT table:

[02Ch 0044   1]                Subtable Type : 00 [Processor Local APIC]
[02Dh 0045   1]                       Length : 08
[02Eh 0046   1]                 Processor ID : 00
[02Fh 0047   1]                Local Apic ID : 00
[030h 0048   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[034h 0052   1]                Subtable Type : 00 [Processor Local APIC]
[035h 0053   1]                       Length : 08
[036h 0054   1]                 Processor ID : 01
[037h 0055   1]                Local Apic ID : 02
[038h 0056   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[03Ch 0060   1]                Subtable Type : 00 [Processor Local APIC]
[03Dh 0061   1]                       Length : 08
[03Eh 0062   1]                 Processor ID : 02
[03Fh 0063   1]                Local Apic ID : 04
[040h 0064   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[044h 0068   1]                Subtable Type : 00 [Processor Local APIC]
[045h 0069   1]                       Length : 08
[046h 0070   1]                 Processor ID : 03
[047h 0071   1]                Local Apic ID : 06
[048h 0072   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[04Ch 0076   1]                Subtable Type : 00 [Processor Local APIC]
[04Dh 0077   1]                       Length : 08
[04Eh 0078   1]                 Processor ID : 04
[04Fh 0079   1]                Local Apic ID : 01
[050h 0080   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[054h 0084   1]                Subtable Type : 00 [Processor Local APIC]
[055h 0085   1]                       Length : 08
[056h 0086   1]                 Processor ID : 05
[057h 0087   1]                Local Apic ID : 03
[058h 0088   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[05Ch 0092   1]                Subtable Type : 00 [Processor Local APIC]
[05Dh 0093   1]                       Length : 08
[05Eh 0094   1]                 Processor ID : 06
[05Fh 0095   1]                Local Apic ID : 05
[060h 0096   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[064h 0100   1]                Subtable Type : 00 [Processor Local APIC]
[065h 0101   1]                       Length : 08
[066h 0102   1]                 Processor ID : 07
[067h 0103   1]                Local Apic ID : 07
[068h 0104   4]        Flags (decoded below) : 00000001
                           Processor Enabled : 1
                      Runtime Online Capable : 0

[06Ch 0108   1]                Subtable Type : 00 [Processor Local APIC]
[06Dh 0109   1]                       Length : 08
[06Eh 0110   1]                 Processor ID : 08
[06Fh 0111   1]                Local Apic ID : FF
[070h 0112   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[074h 0116   1]                Subtable Type : 00 [Processor Local APIC]
[075h 0117   1]                       Length : 08
[076h 0118   1]                 Processor ID : 09
[077h 0119   1]                Local Apic ID : FF
[078h 0120   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[07Ch 0124   1]                Subtable Type : 00 [Processor Local APIC]
[07Dh 0125   1]                       Length : 08
[07Eh 0126   1]                 Processor ID : 0A
[07Fh 0127   1]                Local Apic ID : FF
[080h 0128   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[084h 0132   1]                Subtable Type : 00 [Processor Local APIC]
[085h 0133   1]                       Length : 08
[086h 0134   1]                 Processor ID : 0B
[087h 0135   1]                Local Apic ID : FF
[088h 0136   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[08Ch 0140   1]                Subtable Type : 00 [Processor Local APIC]
[08Dh 0141   1]                       Length : 08
[08Eh 0142   1]                 Processor ID : 0C
[08Fh 0143   1]                Local Apic ID : FF
[090h 0144   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[094h 0148   1]                Subtable Type : 00 [Processor Local APIC]
[095h 0149   1]                       Length : 08
[096h 0150   1]                 Processor ID : 0D
[097h 0151   1]                Local Apic ID : FF
[098h 0152   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[09Ch 0156   1]                Subtable Type : 00 [Processor Local APIC]
[09Dh 0157   1]                       Length : 08
[09Eh 0158   1]                 Processor ID : 0E
[09Fh 0159   1]                Local Apic ID : FF
[0A0h 0160   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

[0A4h 0164   1]                Subtable Type : 00 [Processor Local APIC]
[0A5h 0165   1]                       Length : 08
[0A6h 0166   1]                 Processor ID : 0F
[0A7h 0167   1]                Local Apic ID : FF
[0A8h 0168   4]        Flags (decoded below) : 00000000
                           Processor Enabled : 0
                      Runtime Online Capable : 0

If you wanted something else or need more, just let me know.

Simon

[-- Attachment #1.1.2: detect_extended_topology-dbg.patch --]
[-- Type: text/x-patch, Size: 1023 bytes --]

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index cfcdaace12..8a35a5affe 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -624,7 +624,11 @@ bool detect_extended_topology(struct cpuinfo_x86 *c)
 	if ( c->cpuid_level < 0xb )
 		return false;
 
+	printk("dbg smp_processor_id() = %u\n", smp_processor_id());
+	printk("dbg get_apic_id() = %u\n", get_apic_id());
+
 	cpuid_count(0xb, SMT_LEVEL, &eax, &ebx, &ecx, &edx);
+	printk("dbg cpuid_count(0xb, SMT_LEVEL) = %#x, %#x, %#x, %#x\n", eax, ebx, ecx, edx);
 
 	/* Check if the cpuid leaf 0xb is actually implemented */
 	if ( ebx == 0 || (LEAFB_SUBTYPE(ecx) != SMT_TYPE) )
@@ -641,6 +645,7 @@ bool detect_extended_topology(struct cpuinfo_x86 *c)
 	sub_index = 1;
 	do {
 		cpuid_count(0xb, sub_index, &eax, &ebx, &ecx, &edx);
+		printk("dbg cpuid_count(0xb, %#x) = %#x, %#x, %#x, %#x\n", sub_index, eax, ebx, ecx, edx);
 
 		/* Check for the Core type in the implemented sub leaves */
 		if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Xen-devel] [PATCH v2 04/23] x86: Don't use potentially incorrect CPUID values for topology information

[Andrew Cooper]

On 07/08/2023 9:18 am, Simon Gaiser wrote:
> Anthony Liguori:
>> From: Jan H. Schönherr <jschoenh@amazon.de>
>>
>> Intel says for CPUID leaf 0Bh:
>>
>>   "Software must not use EBX[15:0] to enumerate processor
>>    topology of the system. This value in this field
>>    (EBX[15:0]) is only intended for display/diagnostic
>>    purposes. The actual number of logical processors
>>    available to BIOS/OS/Applications may be different from
>>    the value of EBX[15:0], depending on software and platform
>>    hardware configurations."
>>
>> And yet, we're using them to derive the number cores in a package
>> and the number of siblings in a core.
>>
>> Derive the number of siblings and cores from EAX instead, which is
>> intended for that.
>>
>> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
>> ---
>>  xen/arch/x86/cpu/common.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>> index e9588b3..22f392f 100644
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -479,8 +479,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>  	initial_apicid = edx;
>>  
>>  	/* Populate HT related information from sub-leaf level 0 */
>> -	core_level_siblings = c->x86_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>  	core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>> +	core_level_siblings = c->x86_num_siblings = 1 << ht_mask_width;
>>  
>>  	sub_index = 1;
>>  	do {
>> @@ -488,8 +488,8 @@ void detect_extended_topology(struct cpuinfo_x86 *c)
>>  
>>  		/* Check for the Core type in the implemented sub leaves */
>>  		if ( LEAFB_SUBTYPE(ecx) == CORE_TYPE ) {
>> -			core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>>  			core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>> +			core_level_siblings = 1 << core_plus_mask_width;
>
> On the i5-1135G7 (4 cores with each 2 threads) I'm currently testing on
> I noticed that this changes leads to core_level_siblings == 16 and
> therefore x86_max_cores == 8. If read from ebx like before this change
> and what Linux is still doing [1] it reads core_level_siblings == 8 (as
> expected?).
>
> What's the expected semantic here? If it's to derive the actual number
> of siblings (and therefore cores) in a package as the commit message
> suggest, the new code can't work even ignoring the example from my test
> system. It will always produce powers of 2, so can't get it right on a
> system with, say, 6 cores.
>
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/topology.c?h=v6.4#n126

Topology is broken in many subtle ways, including bits Xen inherited
from Linux.

As it happens, Thomas is working on the Linux side right now, and it's
been quite an effort...

https://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git/log/?h=x86/topo-full

In some copious free time I'll be ste^W borrowing this.  It comes with a
negative diffstat too.

~Andrew

[PATCH v2 05/23] char: optionally redirect {, g}printk output to QEMU debug log

[Anthony Liguori]

From: Matt Wilson <msw@amazon.com>

When using Vixen, it is helpful to get the Xen messages in a
separate channel than the console output.  Add an option to
output to the QEMU backdoor logging port.

Signed-off-by: Matt Wilson <msw@amazon.com>
---
v1 -> v2
 - #ifdef for !x86_64
---
 xen/drivers/char/console.c | 35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 19d0e74..0f85707 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -85,6 +85,11 @@ static int __read_mostly sercon_handle = -1;
 
 static DEFINE_SPINLOCK(console_lock);
 
+/* send all printk output to QEMU debug log. Input does not change,
+ * nor does dom0 output.
+ */
+static bool_t __read_mostly qemu_debug = false;
+
 /*
  * To control the amount of printing, thresholds are added.
  * These thresholds correspond to the XENLOG logging levels.
@@ -560,14 +565,36 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE_PARAM(char) buffer)
 
 static bool_t console_locks_busted;
 
+#if defined(__x86_64__)
+static void qemu_putstr(const char *str)
+{
+    char c;
+    while ( (c = *str++) != '\0' )
+    {
+        outb(c, 0x12);
+    }
+}
+#else
+static void qemu_putstr(const char *str)
+{
+}
+#endif
+
 static void __putstr(const char *str)
 {
     ASSERT(spin_is_locked(&console_lock));
 
-    sercon_puts(str);
-    video_puts(str);
+    if ( qemu_debug )
+    {
+        qemu_putstr(str);
+    }
+    else
+    {
+        sercon_puts(str);
+        video_puts(str);
 
-    conring_puts(str);
+        conring_puts(str);
+    }
 
     if ( !console_locks_busted )
         tasklet_schedule(&notify_dom0_con_ring_tasklet);
@@ -762,6 +789,8 @@ void __init console_init_preirq(void)
             p++;
         if ( !strncmp(p, "vga", 3) )
             video_init();
+        else if ( !strncmp(p, "qemu", 4) )
+            qemu_debug = true;
         else if ( !strncmp(p, "none", 4) )
             continue;
         else if ( (sh = serial_parse_handle(p)) >= 0 )
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 05/23] char: optionally redirect {, g}printk output to QEMU debug log

[Wei Liu]

On Sun, Jan 07, 2018 at 12:28:21PM -0800, Anthony Liguori wrote:
> From: Matt Wilson <msw@amazon.com>
> 
> When using Vixen, it is helpful to get the Xen messages in a
> separate channel than the console output.  Add an option to
> output to the QEMU backdoor logging port.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

I think this should be merged with or built on top of one of the patches
in pv-in-pvh shim series that adds console and magic debug port output.

I will see what I can do.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 06/23] console: do not print banner if below info log threshold

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

Only print the banner if the log threshold is at least info.

For Vixen guests, we want the console output to be exactly what the
PV guest would show on it's own.  That means the inner Xen banner
can potentially break automation that assumes a specific type of
console output.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/drivers/char/console.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 0f85707..3eb130d 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -812,9 +812,12 @@ void __init console_init_preirq(void)
     serial_set_rx_handler(sercon_handle, serial_rx);
 
     /* HELLO WORLD --- start-of-day banner text. */
-    spin_lock(&console_lock);
-    __putstr(xen_banner());
-    spin_unlock(&console_lock);
+    if ( 2 < xenlog_lower_thresh ) {
+        /* Only display at XENLOG_INFO level */
+        spin_lock(&console_lock);
+        __putstr(xen_banner());
+        spin_unlock(&console_lock);
+    }
     printk("Xen version %d.%d%s (%s@%s) (%s) debug=%c " gcov_string " %s\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
            xen_compile_by(), xen_compile_domain(),
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 06/23] console: do not print banner if below info log threshold

[Wei Liu]

On Sun, Jan 07, 2018 at 12:28:22PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>
> 
> Only print the banner if the log threshold is at least info.
> 
> For Vixen guests, we want the console output to be exactly what the
> PV guest would show on it's own.  That means the inner Xen banner
> can potentially break automation that assumes a specific type of
> console output.

:-)

> 
> Signed-off-by: Anthony Liguori <aliguori@amazon.com>

> ---
>  xen/drivers/char/console.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 0f85707..3eb130d 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -812,9 +812,12 @@ void __init console_init_preirq(void)
>      serial_set_rx_handler(sercon_handle, serial_rx);
>  
>      /* HELLO WORLD --- start-of-day banner text. */
> -    spin_lock(&console_lock);
> -    __putstr(xen_banner());
> -    spin_unlock(&console_lock);
> +    if ( 2 < xenlog_lower_thresh ) {

This should become a tunable (command line option?) instead of being
hardcoded.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 07/23] vixen: introduce is_vixen() to allow altering behavior

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

Vixen (Virtualized Xen) is a paravirtual mode of Xen where
paravirtual I/O is passed through from the parent hypervisor
all the way through the dom0 guest.  The dom0 guest is also
deprivileged and renumbered to give the appearance that it
is running as a normal PV guest.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - ARM stubs
---
 xen/arch/x86/guest/Makefile       |  1 +
 xen/arch/x86/guest/vixen.c        | 30 +++++++++++++++
 xen/include/asm-arm/guest/vixen.h | 81 +++++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/guest/vixen.h | 73 +++++++++++++++++++++++++++++++++++
 4 files changed, 185 insertions(+)
 create mode 100644 xen/arch/x86/guest/vixen.c
 create mode 100644 xen/include/asm-arm/guest/vixen.h
 create mode 100644 xen/include/asm-x86/guest/vixen.h

diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
index c5d5188..1c9cd7d 100644
--- a/xen/arch/x86/guest/Makefile
+++ b/xen/arch/x86/guest/Makefile
@@ -1,2 +1,3 @@
 obj-y += hypercall_page.o
 obj-y += xen.o
+obj-y += vixen.o
diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
new file mode 100644
index 0000000..d82e68f
--- /dev/null
+++ b/xen/arch/x86/guest/vixen.c
@@ -0,0 +1,30 @@
+/******************************************************************************
+ * arch/x86/guest/vixen.c
+ *
+ * Support for detecting and running under Xen HVM.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright 2017-2018 Amazon.com, Inc. or its affiliates.
+ */
+
+#include <asm/guest/vixen.h>
+
+static int in_vixen;
+
+bool is_vixen(void)
+{
+    return in_vixen > 0;
+}
+
diff --git a/xen/include/asm-arm/guest/vixen.h b/xen/include/asm-arm/guest/vixen.h
new file mode 100644
index 0000000..ade6724
--- /dev/null
+++ b/xen/include/asm-arm/guest/vixen.h
@@ -0,0 +1,81 @@
+/******************************************************************************
+ * include/asm-x86/guest.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright 2018 Amazon.com, Inc. or its affiliates.
+ */
+
+#ifndef __ARM_GUEST_VIXEN_H__
+#define __ARM_GUEST_VIXEN_H__
+
+#include <xen/types.h>
+
+static inline int
+HYPERVISOR_xen_version(int cmd, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline unsigned long
+HYPERVISOR_hvm_op(int op, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline int
+HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
+{
+    return -ENOSYS;
+}
+
+static inline long
+HYPERVISOR_memory_op(unsigned int cmd, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline int
+HYPERVISOR_event_channel_op(int cmd, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline int
+HYPERVISOR_sched_op(int cmd, void *arg)
+{
+    return -ENOSYS;
+}
+
+static inline int
+HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args)
+{
+    return -ENOSYS;
+}
+
+static inline bool is_vixen(void)
+{
+    return false;
+}
+
+static inline bool vixen_has_per_cpu_notifications(void)
+{
+    return false;
+}
+
+static inline bool vixen_ring_process(uint16_t port)
+{
+    return false;
+}
+
+#endif
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
new file mode 100644
index 0000000..be90c46
--- /dev/null
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -0,0 +1,73 @@
+/******************************************************************************
+ * include/asm-x86/guest/vixen.h
+ *
+ * Support for detecting and running under Xen HVM.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Copyright 2017-2018 Amazon.com, Inc. or its affiliates.
+ */
+
+#ifndef XEN_VIXEN_H
+#define XEN_VIXEN_H
+
+#include <asm/guest.h>
+#include <public/xen.h>
+#include <xen/sched.h>
+
+static inline int
+HYPERVISOR_xen_version(int cmd, void *arg)
+{
+    return _hypercall64_2(int, __HYPERVISOR_xen_version, cmd, arg);
+}
+
+static inline unsigned long
+HYPERVISOR_hvm_op(int op, void *arg)
+{
+   return _hypercall64_2(unsigned long, __HYPERVISOR_hvm_op, op, arg);
+}
+
+static inline int
+HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
+{
+    return _hypercall64_3(int, __HYPERVISOR_grant_table_op, cmd, uop, count);
+}
+
+static inline long
+HYPERVISOR_memory_op(unsigned int cmd, void *arg)
+{
+    return _hypercall64_2(long, __HYPERVISOR_memory_op, cmd, arg);
+}
+
+static inline int
+HYPERVISOR_event_channel_op(int cmd, void *arg)
+{
+    return _hypercall64_2(int, __HYPERVISOR_event_channel_op, cmd, arg);
+}
+
+static inline int
+HYPERVISOR_sched_op(int cmd, void *arg)
+{
+    return _hypercall64_2(int, __HYPERVISOR_sched_op, cmd, arg);
+}
+
+static inline int
+HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args)
+{
+	return _hypercall64_3(int, __HYPERVISOR_vcpu_op, cmd, vcpuid, extra_args);
+}
+
+bool is_vixen(void);
+
+#endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 07/23] vixen: introduce is_vixen() to allow altering behavior

[Wei Liu]

On Sun, Jan 07, 2018 at 12:28:23PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>
> 
> Vixen (Virtualized Xen) is a paravirtual mode of Xen where
> paravirtual I/O is passed through from the parent hypervisor
> all the way through the dom0 guest.  The dom0 guest is also
> deprivileged and renumbered to give the appearance that it
> is running as a normal PV guest.
> 
> Signed-off-by: Anthony Liguori <aliguori@amazon.com>
> +
[...]
> +static inline bool is_vixen(void)
> +{
> +    return false;
> +}
> +
> +static inline bool vixen_has_per_cpu_notifications(void)
> +{
> +    return false;
> +}
> +
> +static inline bool vixen_ring_process(uint16_t port)
> +{
> +    return false;
> +}

AFAICT only these are vixen specific. The rest can be merged with
pv-in-pvh code.

I'm not sure why they are needed yet. If I can figure that out later I
will ask questions here.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 08/23] vixen: allow dom0 to be created with a domid != 0

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

Some older guests special case domid=0 instead of checking the
shared info flags so in order to get PV drivers loaded properly,
we need to make the guest always appear with a domid != 0.

While the Vixen domain is the hardware domain, we don't want it
to behave that way so we also modify the is_hardware_domain()
check.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - allow vixen domain id to be overridden via the Xen command line
---
 xen/arch/x86/dom0_build.c         | 2 +-
 xen/arch/x86/guest/vixen.c        | 7 +++++++
 xen/arch/x86/setup.c              | 2 +-
 xen/common/domain.c               | 4 ++--
 xen/include/asm-arm/guest/vixen.h | 5 +++++
 xen/include/asm-x86/guest/vixen.h | 2 ++
 xen/include/xen/sched.h           | 6 +++++-
 7 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index bf992fe..88810db 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -469,7 +469,7 @@ int __init construct_dom0(struct domain *d, const module_t *image,
     int rc;
 
     /* Sanity! */
-    BUG_ON(d->domain_id != 0);
+    BUG_ON(d->domain_id != dom0_domid);
     BUG_ON(d->vcpu[0] == NULL);
     BUG_ON(d->vcpu[0]->is_initialised);
 
diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index d82e68f..c0a81dd 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -22,9 +22,16 @@
 #include <asm/guest/vixen.h>
 
 static int in_vixen;
+static int vixen_domid = 1;
+
+integer_param("vixen_domid", vixen_domid);
 
 bool is_vixen(void)
 {
     return in_vixen > 0;
 }
 
+int vixen_get_domid(void)
+{
+    return vixen_domid;
+}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7627c3f..f9d087e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1591,7 +1591,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     }
 
     /* Create initial domain 0. */
-    dom0 = domain_create(0, domcr_flags, 0, &config);
+    dom0 = domain_create(dom0_domid, domcr_flags, 0, &config);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
         panic("Error creating domain 0");
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 7af8d12..b4d679e 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -202,7 +202,7 @@ static int late_hwdom_init(struct domain *d)
     struct domain *dom0;
     int rv;
 
-    if ( d != hardware_domain || d->domain_id == 0 )
+    if ( d != hardware_domain || d->domain_id == dom0_domid )
         return 0;
 
     rv = xsm_init_hardware_domain(XSM_HOOK, d);
@@ -310,7 +310,7 @@ struct domain *domain_create(domid_t domid, unsigned int domcr_flags,
     else
         d->guest_type = guest_type_pv;
 
-    if ( domid == 0 || domid == hardware_domid )
+    if ( domid == dom0_domid || domid == hardware_domid )
     {
         if ( hardware_domid < 0 || hardware_domid >= DOMID_FIRST_RESERVED )
             panic("The value of hardware_dom must be a valid domain ID");
diff --git a/xen/include/asm-arm/guest/vixen.h b/xen/include/asm-arm/guest/vixen.h
index ade6724..cb51698 100644
--- a/xen/include/asm-arm/guest/vixen.h
+++ b/xen/include/asm-arm/guest/vixen.h
@@ -78,4 +78,9 @@ static inline bool vixen_ring_process(uint16_t port)
     return false;
 }
 
+static inline int vixen_get_domid(void)
+{
+    return 0;
+}
+
 #endif
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index be90c46..4e80b76 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -70,4 +70,6 @@ HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args)
 
 bool is_vixen(void);
 
+int vixen_get_domid(void);
+
 #endif
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 002ba29..5ddf6a2 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -27,6 +27,8 @@
 #include <public/vcpu.h>
 #include <public/vm_event.h>
 #include <public/event_channel.h>
+#include <asm/guest.h>
+#include <asm/guest/vixen.h>
 
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -54,6 +56,8 @@ extern domid_t hardware_domid;
 #define hardware_domid 0
 #endif
 
+#define dom0_domid (is_vixen() ? vixen_get_domid() : 0)
+
 #ifndef CONFIG_COMPAT
 #define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
 #else
@@ -873,7 +877,7 @@ void watchdog_domain_destroy(struct domain *d);
  *    (that is, this would not be suitable for a driver domain)
  *  - There is never a reason to deny the hardware domain access to this
  */
-#define is_hardware_domain(_d) ((_d) == hardware_domain)
+#define is_hardware_domain(_d) (!is_vixen() && ((_d) == hardware_domain))
 
 /* This check is for functionality specific to a control domain */
 #define is_control_domain(_d) ((_d)->is_privileged)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 08/23] vixen: allow dom0 to be created with a domid != 0

[Wei Liu]

On Sun, Jan 07, 2018 at 12:28:24PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>
> 
> Some older guests special case domid=0 instead of checking the
> shared info flags so in order to get PV drivers loaded properly,
> we need to make the guest always appear with a domid != 0.
> 
> While the Vixen domain is the hardware domain, we don't want it
> to behave that way so we also modify the is_hardware_domain()
> check.
> 
> Signed-off-by: Anthony Liguori <aliguori@amazon.com>
> ---
> v1 -> v2
>  - allow vixen domain id to be overridden via the Xen command line

This patch will can be broken up into two:

1. A patch that modifies is_hardware_domain.
2. A patch that adds the domid command line option.

But I think the first patch is not required because the pv-in-pvh shim
works fine even if the guest is not hardware domain.

Please don't do any real work yet -- we need to agree on the things
in the my reply to the cover letter first.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 09/23] vixen: modify the e820 table to advertise HVM special pages as RAM

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

In order to be able to assign the Xenstore page into the Vixen guest,
we need struct page_info's to exist.  We do this by modifying the
e820 table early in boot and then using the badpages handling to
prevent these pages from being added to the xenheap.

Since these pages exist in a somewhat weird state in Xen, we need
to relax permission checking too in order to be able to assign them
to the guest.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - lay the ground work to use hvm_info_table to determine range
---
 xen/arch/x86/e820.c               | 11 +++++++++++
 xen/arch/x86/guest/vixen.c        |  9 +++++++++
 xen/arch/x86/mm.c                 |  3 ++-
 xen/common/page_alloc.c           |  7 +++++++
 xen/include/asm-x86/guest/vixen.h |  2 ++
 5 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 7c572ba..78ab8db 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -9,6 +9,7 @@
 #include <asm/processor.h>
 #include <asm/mtrr.h>
 #include <asm/msr.h>
+#include <asm/guest/vixen.h>
 
 /*
  * opt_mem: Limit maximum address of physical RAM.
@@ -698,6 +699,16 @@ unsigned long __init init_e820(const char *str, struct e820map *raw)
         print_e820_memory_map(raw->map, raw->nr_map);
     }
 
+    if ( is_vixen() )
+    {
+        unsigned long start_pfn, end_pfn;
+
+        vixen_get_reserved_mem(&start_pfn, &end_pfn);
+
+        /* Pretend that passed through special pages are RAM */
+        e820_change_range_type(raw, start_pfn << XEN_PAGE_SHIFT,
+                               end_pfn << XEN_PAGE_SHIFT, E820_RESERVED, E820_RAM);
+    }
     machine_specific_memory_setup(raw);
 
     printk("%s RAM map:\n", str);
diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index c0a81dd..cacbe69 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -23,6 +23,7 @@
 
 static int in_vixen;
 static int vixen_domid = 1;
+static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
 
 integer_param("vixen_domid", vixen_domid);
 
@@ -35,3 +36,11 @@ int vixen_get_domid(void)
 {
     return vixen_domid;
 }
+
+void vixen_get_reserved_mem(unsigned long *start_pfn, unsigned long *end_pfn)
+{
+    *start_pfn = vixen_reserved_mem_pgstart >> XEN_PAGE_SHIFT;
+
+    /* This is part of the Xen ABI */
+    *end_pfn   = 0x100000;
+}
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a56f875..f0260ea 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -122,6 +122,7 @@
 #include <asm/fixmap.h>
 #include <asm/io_apic.h>
 #include <asm/pci.h>
+#include <asm/guest.h>
 
 #include <asm/hvm/grant_table.h>
 #include <asm/pv/grant_table.h>
@@ -945,7 +946,7 @@ get_page_from_l1e(
             case 0:
                 break;
             case 1:
-                if ( !is_hardware_domain(l1e_owner) )
+                if ( !is_vixen() && !is_hardware_domain(l1e_owner) )
                     break;
                 /* fallthrough */
             case -1:
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index c0c2d82..35a433d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -303,6 +303,13 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
             badpage++;
         }
     }
+
+    if ( is_vixen() ) {
+        unsigned long start_pfn, end_pfn;
+
+        vixen_get_reserved_mem(&start_pfn, &end_pfn);
+        bootmem_region_zap(start_pfn, end_pfn);
+    }
 #endif
 
     /* Check new pages against the bad-page list. */
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index 4e80b76..fb8e871 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -72,4 +72,6 @@ bool is_vixen(void);
 
 int vixen_get_domid(void);
 
+void vixen_get_reserved_mem(unsigned long *start_pfn, unsigned long *end_pfn);
+
 #endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 09/23] vixen: modify the e820 table to advertise HVM special pages as RAM

[Konrad Rzeszutek Wilk]

On Sun, Jan 07, 2018 at 12:28:25PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>

..snip.
> diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
> index c0a81dd..cacbe69 100644
> --- a/xen/arch/x86/guest/vixen.c
> +++ b/xen/arch/x86/guest/vixen.c
> @@ -23,6 +23,7 @@
>  
>  static int in_vixen;
>  static int vixen_domid = 1;
> +static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;

This is interesting. Would it make sense to have this be
auto-detected? Or a boot parameter to over-write?

>  
>  integer_param("vixen_domid", vixen_domid);
>  
> @@ -35,3 +36,11 @@ int vixen_get_domid(void)
>  {
>      return vixen_domid;
>  }
> +
> +void vixen_get_reserved_mem(unsigned long *start_pfn, unsigned long *end_pfn)
> +{
> +    *start_pfn = vixen_reserved_mem_pgstart >> XEN_PAGE_SHIFT;
> +
> +    /* This is part of the Xen ABI */

.. which one :-) ?
> +    *end_pfn   = 0x100000;
> +}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 09/23] vixen: modify the e820 table to advertise HVM special pages as RAM

[Anthony Liguori]

On Sun, Jan 7, 2018 at 4:18 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jan 07, 2018 at 12:28:25PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori <aliguori@amazon.com>
>
> ..snip.
>> diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
>> index c0a81dd..cacbe69 100644
>> --- a/xen/arch/x86/guest/vixen.c
>> +++ b/xen/arch/x86/guest/vixen.c
>> @@ -23,6 +23,7 @@
>>
>>  static int in_vixen;
>>  static int vixen_domid = 1;
>> +static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
>
> This is interesting. Would it make sense to have this be
> auto-detected? Or a boot parameter to over-write?

This is done in a later patch (the one that sets up event channels).

It cannot be done here because we don't have enough infrastructure.

>>  integer_param("vixen_domid", vixen_domid);
>>
>> @@ -35,3 +36,11 @@ int vixen_get_domid(void)
>>  {
>>      return vixen_domid;
>>  }
>> +
>> +void vixen_get_reserved_mem(unsigned long *start_pfn, unsigned long *end_pfn)
>> +{
>> +    *start_pfn = vixen_reserved_mem_pgstart >> XEN_PAGE_SHIFT;
>> +
>> +    /* This is part of the Xen ABI */
>
> .. which one :-) ?

include/public/hvm/hvm_info_table.h.  See the comment around
reserved_mem_pgstart.

Regards,

Anthony Liguori

>> +    *end_pfn   = 0x100000;
>> +}
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 10/23] vixen: do not permit access to physical IRQs if in Vixen mode

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

Our intention is for the Vixen guest to be deprivileged so we need
to avoid permitting access to each IRQ even though it is technically
the hardware domain.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/arch/x86/irq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 87ef2e8..bd75108 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -25,6 +25,7 @@
 #include <asm/flushtlb.h>
 #include <asm/mach-generic/mach_apic.h>
 #include <public/physdev.h>
+#include <asm/guest/vixen.h>
 
 static int parse_irq_vector_map_param(const char *s);
 
@@ -190,7 +191,7 @@ int create_irq(nodeid_t node)
         desc->arch.used = IRQ_UNUSED;
         irq = ret;
     }
-    else if ( hardware_domain )
+    else if ( !is_vixen() && hardware_domain )
     {
         ret = irq_permit_access(hardware_domain, irq);
         if ( ret )
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 11/23] vixen: early initialization of Vixen including shared_info mapping

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

We split initialization of Vixen into two parts.  The first part
just detects the presence of an HVM hypervisor so that we can
figure out whether to modify the e820 table.

The later initialization is used to actually map the shared_info
structure from the parent hypervisor into Xen.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - allow disabling vixen by specifying vixen_domid=-1 on command line
 - use hvm_info_table for reserved region if still valid
 - use reserved region for shared_info instead of BSS
---
 xen/arch/x86/guest/vixen.c        | 76 +++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/setup.c              |  5 +++
 xen/include/asm-x86/guest/vixen.h |  4 +++
 3 files changed, 85 insertions(+)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index cacbe69..1ad5bd7 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -20,13 +20,89 @@
  */
 
 #include <asm/guest/vixen.h>
+#include <public/version.h>
+#include <public/hvm/hvm_info_table.h>
+
+#define X86_HVM_END_SPECIAL_REGION  0xff000u
+
+#define SHARED_INFO_PFN		(X86_HVM_END_SPECIAL_REGION + 0)
 
 static int in_vixen;
 static int vixen_domid = 1;
 static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
+static shared_info_t *global_si;
 
 integer_param("vixen_domid", vixen_domid);
 
+void __init init_vixen(void)
+{
+    int major, minor, version;
+    struct hvm_info_table *hvm_info;
+
+    if ( !xen_guest )
+    {
+        printk("Disabling Vixen because we are not running under Xen\n");
+        in_vixen = -1;
+        return;
+    }
+
+    if ( vixen_domid < 0 )
+    {
+        printk("Disabling Vixen due to user request\n");
+        in_vixen = -1;
+        return;
+    }
+
+    version = HYPERVISOR_xen_version(XENVER_version, NULL);
+    major = version >> 16;
+    minor = version & 0xffff;
+
+    printk("Vixen running under Xen %d.%d\n", major, minor);
+
+    hvm_info = maddr_to_virt(HVM_INFO_PADDR);
+    if ( strncmp(hvm_info->signature, "HVM INFO", 8) == 0 &&
+	 hvm_info->length >= sizeof(struct hvm_info_table) &&
+	 hvm_info->length < (PAGE_SIZE - HVM_INFO_OFFSET) )
+    {
+	uint8_t sum;
+	uint32_t i;
+
+	for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+	    sum += ((uint8_t *)hvm_info)[i];
+
+	if ( sum == 0 )
+	{
+	    vixen_reserved_mem_pgstart = hvm_info->reserved_mem_pgstart << XEN_PAGE_SHIFT;
+	}
+    }
+
+    in_vixen = 1;
+}
+
+void __init early_vixen_init(void)
+{
+    struct xen_add_to_physmap xatp;
+    long rc;
+
+    if ( !is_vixen() )
+	return;
+
+    global_si = mfn_to_virt(SHARED_INFO_PFN);
+
+    /* Setup our own shared info area */
+    xatp.domid = DOMID_SELF;
+    xatp.idx = 0;
+    xatp.space = XENMAPSPACE_shared_info;
+    xatp.gpfn = virt_to_mfn(global_si);
+
+    rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+    if ( rc < 0 )
+        printk("Setting shared info page failed: %ld\n", rc);
+
+    memset(&global_si->native.evtchn_mask[0], 0x00,
+           sizeof(global_si->native.evtchn_mask));
+}
+
 bool is_vixen(void)
 {
     return in_vixen > 0;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f9d087e..07239c0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -869,6 +869,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     else
         panic("Bootloader provided no memory information.");
 
+    /* Vixen must be initialized before init_e820() */
+    init_vixen();
+
     /* Sanitise the raw E820 map to produce a final clean version. */
     max_page = raw_max_page = init_e820(memmap_type, &e820_raw);
 
@@ -1516,6 +1519,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     rcu_init();
 
+    early_vixen_init();
+
     early_time_init();
 
     arch_init_memory();
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index fb8e871..0c040ee 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -74,4 +74,8 @@ int vixen_get_domid(void);
 
 void vixen_get_reserved_mem(unsigned long *start_pfn, unsigned long *end_pfn);
 
+void __init init_vixen(void);
+
+void __init early_vixen_init(void);
+
 #endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 12/23] vixen: paravirtualization TSC frequency calculation

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

Otherwise when time sharing a physical CPU, the calculation can
be bogus resulting in time drift for the guest due to improper
frequency within pvclock.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/arch/x86/guest/vixen.c        | 22 ++++++++++++++++++++++
 xen/arch/x86/time.c               |  9 ++++++++-
 xen/include/asm-x86/guest/vixen.h |  2 ++
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index 1ad5bd7..a1614e0 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -120,3 +120,25 @@ void vixen_get_reserved_mem(unsigned long *start_pfn, unsigned long *end_pfn)
     /* This is part of the Xen ABI */
     *end_pfn   = 0x100000;
 }
+
+u64 vixen_get_cpu_freq(void)
+{
+    volatile vcpu_time_info_t *timep = &global_si->native.vcpu_info[0].time;
+    vcpu_time_info_t time;
+    uint32_t version;
+    u64 imm;
+
+    do {
+	version = timep->version;
+	rmb();
+	time = *timep;
+    } while ((version & 1) || version != time.version);
+
+    imm = (1000000000ULL << 32) / time.tsc_to_system_mul;
+
+    if (time.tsc_shift < 0) {
+	return imm << -time.tsc_shift;
+    } else {
+	return imm >> time.tsc_shift;
+    }
+}
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 2a87950..04c0fbb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -36,6 +36,7 @@
 #include <io_ports.h>
 #include <asm/setup.h> /* for early_time_init */
 #include <public/arch-x86/cpuid.h>
+#include <asm/guest/vixen.h>
 
 /* opt_clocksource: Force clocksource to one of: pit, hpet, acpi. */
 static char __initdata opt_clocksource[10];
@@ -1687,6 +1688,12 @@ void __init early_time_init(void)
 
     preinit_pit();
     tmp = init_platform_timer();
+
+    /* We cannot trust calibrated values when running under
+     * a hypervisor. */
+    if ( is_vixen() )
+        tmp = vixen_get_cpu_freq();
+
     plt_tsc.frequency = tmp;
 
     set_time_scale(&t->tsc_scale, tmp);
@@ -2014,7 +2021,7 @@ void tsc_set_info(struct domain *d,
                   uint32_t tsc_mode, uint64_t elapsed_nsec,
                   uint32_t gtsc_khz, uint32_t incarnation)
 {
-    if ( is_idle_domain(d) || is_hardware_domain(d) )
+    if ( is_idle_domain(d) || is_vixen() || is_hardware_domain(d) )
     {
         d->arch.vtsc = 0;
         return;
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index 0c040ee..e6b64f2 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -78,4 +78,6 @@ void __init init_vixen(void);
 
 void __init early_vixen_init(void);
 
+u64 vixen_get_cpu_freq(void);
+
 #endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 12/23] vixen: paravirtualization TSC frequency calculation

[Wei Liu]

On Sun, Jan 07, 2018 at 12:28:28PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>
> 
> Otherwise when time sharing a physical CPU, the calculation can
> be bogus resulting in time drift for the guest due to improper
> frequency within pvclock.
> 

What clock source is vixen using? What about using the xen pvclock
source patch in the pv-in-pvh shim series?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 13/23] vixen: Use SCHEDOP_shutdown to shutdown the machine

[Anthony Liguori]

From: Jan H. Schönherr <jschoenh@amazon.de>

While the hwdom_shutdown() is able to reboot the system, it fails to
properly power it off. With SCHEDOP_shutdown, we delegate the problem.

Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
---
 xen/common/domain.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index b4d679e..ede377c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -42,6 +42,7 @@
 #include <xen/trace.h>
 #include <xen/tmem.h>
 #include <asm/setup.h>
+#include <asm/guest/vixen.h>
 
 /* Linux config option: propageted to domain0 */
 /* xen_processor_pmbits: xen control Cx, Px, ... */
@@ -693,6 +694,17 @@ void __domain_crash_synchronous(void)
 }
 
 
+static void vixen_shutdown(u8 reason)
+{
+    struct sched_shutdown sched_shutdown = { .reason = reason };
+
+    if (!opt_noreboot)
+        HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
+
+    /* Fallback, in case the hypercall fails */
+    hwdom_shutdown(reason);
+}
+ 
 void domain_shutdown(struct domain *d, u8 reason)
 {
     struct vcpu *v;
@@ -703,6 +715,8 @@ void domain_shutdown(struct domain *d, u8 reason)
         d->shutdown_code = reason;
     reason = d->shutdown_code;
 
+    if ( is_vixen() )
+        vixen_shutdown(reason);
     if ( is_hardware_domain(d) )
         hwdom_shutdown(reason);
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 13/23] vixen: Use SCHEDOP_shutdown to shutdown the machine

[Konrad Rzeszutek Wilk]

On Sun, Jan 07, 2018 at 12:28:29PM -0800, Anthony Liguori wrote:
> From: Jan H. Schönherr <jschoenh@amazon.de>
> 
> While the hwdom_shutdown() is able to reboot the system, it fails to
> properly power it off. With SCHEDOP_shutdown, we delegate the problem.
> 
> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
> ---
>  xen/common/domain.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b4d679e..ede377c 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -42,6 +42,7 @@
>  #include <xen/trace.h>
>  #include <xen/tmem.h>
>  #include <asm/setup.h>
> +#include <asm/guest/vixen.h>
>  
>  /* Linux config option: propageted to domain0 */
>  /* xen_processor_pmbits: xen control Cx, Px, ... */
> @@ -693,6 +694,17 @@ void __domain_crash_synchronous(void)
>  }
>  
>  
> +static void vixen_shutdown(u8 reason)
> +{
> +    struct sched_shutdown sched_shutdown = { .reason = reason };
> +
> +    if (!opt_noreboot)

Forgot the spaces around it..
(Not that this matters that much).
> +        HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
> +
> +    /* Fallback, in case the hypercall fails */
> +    hwdom_shutdown(reason);
> +}
> + 
>  void domain_shutdown(struct domain *d, u8 reason)
>  {
>      struct vcpu *v;
> @@ -703,6 +715,8 @@ void domain_shutdown(struct domain *d, u8 reason)
>          d->shutdown_code = reason;
>      reason = d->shutdown_code;
>  
> +    if ( is_vixen() )
> +        vixen_shutdown(reason);
>      if ( is_hardware_domain(d) )
>          hwdom_shutdown(reason);
>  
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 13/23] vixen: Use SCHEDOP_shutdown to shutdown the machine

[Anthony Liguori]

On Sun, Jan 7, 2018 at 4:22 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jan 07, 2018 at 12:28:29PM -0800, Anthony Liguori wrote:
>> From: Jan H. Schönherr <jschoenh@amazon.de>
>>
>> While the hwdom_shutdown() is able to reboot the system, it fails to
>> properly power it off. With SCHEDOP_shutdown, we delegate the problem.
>>
>> Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
>> ---
>>  xen/common/domain.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index b4d679e..ede377c 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -42,6 +42,7 @@
>>  #include <xen/trace.h>
>>  #include <xen/tmem.h>
>>  #include <asm/setup.h>
>> +#include <asm/guest/vixen.h>
>>
>>  /* Linux config option: propageted to domain0 */
>>  /* xen_processor_pmbits: xen control Cx, Px, ... */
>> @@ -693,6 +694,17 @@ void __domain_crash_synchronous(void)
>>  }
>>
>>
>> +static void vixen_shutdown(u8 reason)
>> +{
>> +    struct sched_shutdown sched_shutdown = { .reason = reason };
>> +
>> +    if (!opt_noreboot)
>
> Forgot the spaces around it..
> (Not that this matters that much).

Blarg, I will take a pass through all of the patches and scrub them.

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 14/23] vixen: forward VCPUOP_register_runstate_memory_area to outer Xen

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

This allows for proper accounting of steal time within the guest.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/common/domain.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index ede377c..780f8ff 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1414,6 +1414,12 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( !guest_handle_okay(area.addr.h, 1) )
             break;
 
+        if ( is_vixen() ) {
+            rc = HYPERVISOR_vcpu_op(VCPUOP_register_runstate_memory_area,
+                                    vcpuid, &area);
+            break;
+        }
+
         rc = 0;
         runstate_guest(v) = area.addr.h;
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 15/23] vixen: pass through version hypercalls to parent Xen

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

This is necessary to trigger event channel upcalls but it is also
useful to passthrough the full version information such that the
guest believes it is running on the parent Xen.

Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - don't pass through version by default
 - introduce vixen_ptver parameter to enable version passthrough.
---
 xen/arch/x86/guest/vixen.c        |  7 +++
 xen/common/kernel.c               | 89 +++++++++++++++++++++++++++++++++------
 xen/include/asm-arm/guest/vixen.h |  5 +++
 xen/include/asm-x86/guest/vixen.h |  2 +
 4 files changed, 91 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index a1614e0..7c886a2 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -31,8 +31,10 @@ static int in_vixen;
 static int vixen_domid = 1;
 static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
 static shared_info_t *global_si;
+static bool vixen_ptver;
 
 integer_param("vixen_domid", vixen_domid);
+boolean_param("vixen_ptver", vixen_ptver);
 
 void __init init_vixen(void)
 {
@@ -142,3 +144,8 @@ u64 vixen_get_cpu_freq(void)
 	return imm >> time.tsc_shift;
     }
 }
+
+bool vixen_passthru_version(void)
+{
+    return is_vixen() && vixen_ptver;
+}
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8d137c5..ac85bea 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -15,6 +15,7 @@
 #include <xsm/xsm.h>
 #include <asm/current.h>
 #include <public/version.h>
+#include <asm/guest/vixen.h>
 
 #ifndef COMPAT
 
@@ -311,14 +312,39 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     switch ( cmd )
     {
     case XENVER_version:
-        return (xen_major_version() << 16) | xen_minor_version();
+        if ( vixen_passthru_version() )
+            return HYPERVISOR_xen_version(XENVER_version, NULL);
+        else
+        {
+            /* This hypercall is used to force event channel injections
+               after re-enabling interrupts so if we're Vixen, we need
+               to invoke the parent. */
+            if ( is_vixen() )
+                (void)HYPERVISOR_xen_version(0, NULL);
+            return (xen_major_version() << 16) | xen_minor_version();
+        }
 
     case XENVER_extraversion:
     {
         xen_extraversion_t extraversion;
+        int rc;
 
         memset(extraversion, 0, sizeof(extraversion));
-        safe_strcpy(extraversion, deny ? xen_deny() : xen_extra_version());
+        if ( vixen_passthru_version() )
+        {
+            if ( deny )
+                safe_strcpy(extraversion, xen_deny());
+            else
+            {
+                rc = HYPERVISOR_xen_version(XENVER_extraversion, &extraversion);
+                if ( rc )
+                    return rc;
+            }
+        }
+        else
+        {
+            safe_strcpy(extraversion, deny ? xen_deny() : xen_extra_version());
+        }
         if ( copy_to_guest(arg, extraversion, ARRAY_SIZE(extraversion)) )
             return -EFAULT;
         return 0;
@@ -327,12 +353,22 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case XENVER_compile_info:
     {
         xen_compile_info_t info;
+        int rc;
 
         memset(&info, 0, sizeof(info));
-        safe_strcpy(info.compiler,       deny ? xen_deny() : xen_compiler());
-        safe_strcpy(info.compile_by,     deny ? xen_deny() : xen_compile_by());
-        safe_strcpy(info.compile_domain, deny ? xen_deny() : xen_compile_domain());
-        safe_strcpy(info.compile_date,   deny ? xen_deny() : xen_compile_date());
+        if ( vixen_passthru_version() )
+        {
+            rc = HYPERVISOR_xen_version(XENVER_compile_info, &info);
+            if ( rc )
+                return rc;
+        }
+        else
+        {
+            safe_strcpy(info.compiler,       deny ? xen_deny() : xen_compiler());
+            safe_strcpy(info.compile_by,     deny ? xen_deny() : xen_compile_by());
+            safe_strcpy(info.compile_domain, deny ? xen_deny() : xen_compile_domain());
+            safe_strcpy(info.compile_date,   deny ? xen_deny() : xen_compile_date());
+        }
         if ( copy_to_guest(arg, &info, 1) )
             return -EFAULT;
         return 0;
@@ -366,9 +402,24 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case XENVER_changeset:
     {
         xen_changeset_info_t chgset;
+        int rc;
 
         memset(chgset, 0, sizeof(chgset));
-        safe_strcpy(chgset, deny ? xen_deny() : xen_changeset());
+        if ( vixen_passthru_version() )
+        {
+            if ( deny )
+                safe_strcpy(chgset, xen_deny());
+            else
+            {
+                rc = HYPERVISOR_xen_version(XENVER_changeset, &chgset);
+                if ( rc )
+                    return rc;
+            }
+        }
+        else
+        {
+            safe_strcpy(chgset, deny ? xen_deny() : xen_changeset());
+        }
         if ( copy_to_guest(arg, chgset, ARRAY_SIZE(chgset)) )
             return -EFAULT;
         return 0;
@@ -430,15 +481,29 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case XENVER_guest_handle:
     {
         xen_domain_handle_t hdl;
+        int rc;
 
-        if ( deny )
-            memset(&hdl, 0, ARRAY_SIZE(hdl));
+        memset(&hdl, 0, ARRAY_SIZE(hdl));
 
         BUILD_BUG_ON(ARRAY_SIZE(current->domain->handle) != ARRAY_SIZE(hdl));
 
-        if ( copy_to_guest(arg, deny ? hdl : current->domain->handle,
-                           ARRAY_SIZE(hdl) ) )
-            return -EFAULT;
+        if ( vixen_passthru_version() )
+        {
+            if ( !deny )
+            {
+                rc = HYPERVISOR_xen_version(XENVER_guest_handle, &hdl);
+                if ( rc )
+                    return rc;
+            }
+            if ( copy_to_guest(arg, hdl, ARRAY_SIZE(hdl) ) )
+                return -EFAULT;
+        }
+        else
+        {
+            if ( copy_to_guest(arg, deny ? hdl : current->domain->handle,
+                               ARRAY_SIZE(hdl) ) )
+                return -EFAULT;
+        }
         return 0;
     }
 
diff --git a/xen/include/asm-arm/guest/vixen.h b/xen/include/asm-arm/guest/vixen.h
index cb51698..af932e3 100644
--- a/xen/include/asm-arm/guest/vixen.h
+++ b/xen/include/asm-arm/guest/vixen.h
@@ -83,4 +83,9 @@ static inline int vixen_get_domid(void)
     return 0;
 }
 
+static bool vixen_passthru_version(void)
+{
+    return false;
+}
+
 #endif
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index e6b64f2..fbbc62c 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -80,4 +80,6 @@ void __init early_vixen_init(void);
 
 u64 vixen_get_cpu_freq(void);
 
+bool vixen_passthru_version(void);
+
 #endif
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 15/23] vixen: pass through version hypercalls to parent Xen

[Konrad Rzeszutek Wilk]

On Sun, Jan 07, 2018 at 12:28:31PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>
> 
> This is necessary to trigger event channel upcalls but it is also
> useful to passthrough the full version information such that the
> guest believes it is running on the parent Xen.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>
> Signed-off-by: Anthony Liguori <aliguori@amazon.com>
> ---
> v1 -> v2
>  - don't pass through version by default
>  - introduce vixen_ptver parameter to enable version passthrough.
> ---
>  xen/arch/x86/guest/vixen.c        |  7 +++
>  xen/common/kernel.c               | 89 +++++++++++++++++++++++++++++++++------
>  xen/include/asm-arm/guest/vixen.h |  5 +++
>  xen/include/asm-x86/guest/vixen.h |  2 +
>  4 files changed, 91 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
> index a1614e0..7c886a2 100644
> --- a/xen/arch/x86/guest/vixen.c
> +++ b/xen/arch/x86/guest/vixen.c
> @@ -31,8 +31,10 @@ static int in_vixen;
>  static int vixen_domid = 1;
>  static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
>  static shared_info_t *global_si;
> +static bool vixen_ptver;
>  
>  integer_param("vixen_domid", vixen_domid);
> +boolean_param("vixen_ptver", vixen_ptver);

Would it make sense to have a custom parameter function that would
be called 'vixen' and have all of those in it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 15/23] vixen: pass through version hypercalls to parent Xen

[Anthony Liguori]

On Sun, Jan 7, 2018 at 4:27 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jan 07, 2018 at 12:28:31PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori <aliguori@amazon.com>
>>
>> This is necessary to trigger event channel upcalls but it is also
>> useful to passthrough the full version information such that the
>> guest believes it is running on the parent Xen.
>>
>> Signed-off-by: Matt Wilson <msw@amazon.com>
>> Signed-off-by: Anthony Liguori <aliguori@amazon.com>
>> ---
>> v1 -> v2
>>  - don't pass through version by default
>>  - introduce vixen_ptver parameter to enable version passthrough.
>> ---
>>  xen/arch/x86/guest/vixen.c        |  7 +++
>>  xen/common/kernel.c               | 89 +++++++++++++++++++++++++++++++++------
>>  xen/include/asm-arm/guest/vixen.h |  5 +++
>>  xen/include/asm-x86/guest/vixen.h |  2 +
>>  4 files changed, 91 insertions(+), 12 deletions(-)
>>
>> diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
>> index a1614e0..7c886a2 100644
>> --- a/xen/arch/x86/guest/vixen.c
>> +++ b/xen/arch/x86/guest/vixen.c
>> @@ -31,8 +31,10 @@ static int in_vixen;
>>  static int vixen_domid = 1;
>>  static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
>>  static shared_info_t *global_si;
>> +static bool vixen_ptver;
>>
>>  integer_param("vixen_domid", vixen_domid);
>> +boolean_param("vixen_ptver", vixen_ptver);
>
> Would it make sense to have a custom parameter function that would
> be called 'vixen' and have all of those in it?

Can you give an example?  I'm not sure what you mean.

Regards,

Anthony Liguori


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 15/23] vixen: pass through version hypercalls to parent Xen

[Konrad Rzeszutek Wilk]

> >>  integer_param("vixen_domid", vixen_domid);
> >> +boolean_param("vixen_ptver", vixen_ptver);
> >
> > Would it make sense to have a custom parameter function that would
> > be called 'vixen' and have all of those in it?
> 
> Can you give an example?  I'm not sure what you mean.

Andrew's bti= handling for example.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 16/23] vixen: pass grant table operations through to the outer Xen

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

The grant table is a region of guest memory that contains GMFNs
which in PV are MFNs but are PFNs in HVM.  Since a Vixen guest MFN
is an HVM PFN, we can pass this table directly through to the outer
Xen which cuts down considerably on overhead.

We do not forward most of the hypercalls since we only intend on
Vixen to be used for normal guests, not driver domains.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - move to using reserved memory space for grant table instead of heap
 - use a dispatch function instead of modifying all calls
---
 xen/arch/x86/guest/vixen.c |   4 ++
 xen/common/grant_table.c   | 101 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index 7c886a2..2437c92 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -22,10 +22,14 @@
 #include <asm/guest/vixen.h>
 #include <public/version.h>
 #include <public/hvm/hvm_info_table.h>
+#include <xen/grant_table.h>
+
+#define PCI_DEVICE_ID_XENSOURCE_PLATFORM	0x0001
 
 #define X86_HVM_END_SPECIAL_REGION  0xff000u
 
 #define SHARED_INFO_PFN		(X86_HVM_END_SPECIAL_REGION + 0)
+#define GRANT_TABLE_PFN_0	(X86_HVM_END_SPECIAL_REGION + 1)
 
 static int in_vixen;
 static int vixen_domid = 1;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 250450b..60a7941 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -39,6 +39,7 @@
 #include <xen/vmap.h>
 #include <xsm/xsm.h>
 #include <asm/flushtlb.h>
+#include <asm/guest.h>
 
 /* Per-domain grant information. */
 struct grant_table {
@@ -1801,6 +1802,56 @@ grant_table_init(struct domain *d, struct grant_table *gt,
 }
 
 static long
+vixen_gnttab_setup_table(
+    XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
+{
+    long rc;
+
+    struct gnttab_setup_table op;
+    xen_pfn_t *frame_list = NULL;
+    XEN_GUEST_HANDLE(xen_pfn_t) old_frame_list;
+
+    if ( count != 1 )
+        return -EINVAL;
+
+    if ( unlikely(copy_from_guest(&op, uop, 1) != 0) )
+    {
+        gdprintk(XENLOG_INFO, "Fault while reading gnttab_setup_table_t.\n");
+        return -EFAULT;
+    }
+
+    if ( op.nr_frames > 0 ) {
+        frame_list = xzalloc_array(xen_pfn_t, op.nr_frames);
+        if ( frame_list == NULL )
+            return -ENOMEM;
+    }
+
+    old_frame_list = op.frame_list;
+    op.frame_list.p = frame_list;
+
+    rc = HYPERVISOR_grant_table_op(GNTTABOP_setup_table, &op, count);
+    op.frame_list = old_frame_list;
+
+    if ( rc >= 0 ) {
+        if ( op.status == 0 && op.nr_frames &&
+             copy_to_guest(old_frame_list, frame_list, op.nr_frames) != 0 ) {
+            rc = -EFAULT;
+            goto out;
+        }
+
+        if ( unlikely(copy_to_guest(uop, &op, 1)) != 0 ) {
+            rc = -EFAULT;
+            goto out;
+        }
+    }
+
+ out:
+    xfree(frame_list);
+
+    return rc;
+}
+
+static long
 gnttab_setup_table(
     XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count,
     unsigned int limit_max)
@@ -1892,6 +1943,26 @@ gnttab_setup_table(
 }
 
 static long
+vixen_gnttab_query_size(
+    XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count)
+{
+    struct gnttab_query_size op;
+    int rc;
+
+    if ( count != 1 )
+        return -EINVAL;
+
+    if ( unlikely(copy_from_guest(&op, uop, 1)) != 0)
+        return -EFAULT;
+
+    rc = HYPERVISOR_grant_table_op(GNTTABOP_query_size, &op, count);
+    if (rc == 0 && unlikely(__copy_to_guest(uop, &op, 1)) )
+        rc = -EFAULT;
+
+    return rc;
+}
+
+static long
 gnttab_query_size(
     XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count)
 {
@@ -3311,6 +3382,33 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) uop,
     return 0;
 }
 
+static long
+vixen_do_grant_table_op(
+    unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
+{
+    long rc;
+
+    rc = -EFAULT;
+    switch ( cmd )
+    {
+    case GNTTABOP_setup_table:
+        rc = vixen_gnttab_setup_table(
+            guest_handle_cast(uop, gnttab_setup_table_t), count);
+        break;
+
+    case GNTTABOP_query_size:
+        rc = vixen_gnttab_query_size(
+            guest_handle_cast(uop, gnttab_query_size_t), count);
+        break;
+
+    default:
+        rc = -ENOSYS;
+        break;
+    }
+
+    return rc;
+ }
+
 long
 do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
@@ -3324,6 +3422,9 @@ do_grant_table_op(
     if ( (cmd &= GNTTABOP_CMD_MASK) != GNTTABOP_cache_flush && opaque_in )
         return -EINVAL;
 
+    if ( is_vixen() )
+        return vixen_do_grant_table_op(cmd, uop, count);
+
     rc = -EFAULT;
     switch ( cmd )
     {
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 16/23] vixen: pass grant table operations through to the outer Xen

[Roger Pau Monné]

On Sun, Jan 07, 2018 at 12:28:32PM -0800, Anthony Liguori wrote:
>  static long
> +vixen_gnttab_setup_table(
> +    XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
> +{
> +    long rc;
> +
> +    struct gnttab_setup_table op;
> +    xen_pfn_t *frame_list = NULL;
> +    XEN_GUEST_HANDLE(xen_pfn_t) old_frame_list;
> +
> +    if ( count != 1 )
> +        return -EINVAL;
> +
> +    if ( unlikely(copy_from_guest(&op, uop, 1) != 0) )
> +    {
> +        gdprintk(XENLOG_INFO, "Fault while reading gnttab_setup_table_t.\n");
> +        return -EFAULT;
> +    }
> +
> +    if ( op.nr_frames > 0 ) {
> +        frame_list = xzalloc_array(xen_pfn_t, op.nr_frames);
> +        if ( frame_list == NULL )
> +            return -ENOMEM;
> +    }
> +
> +    old_frame_list = op.frame_list;
> +    op.frame_list.p = frame_list;
> +
> +    rc = HYPERVISOR_grant_table_op(GNTTABOP_setup_table, &op, count);
> +    op.frame_list = old_frame_list;

Are you sure this works? HVM based guests need to use
XENMAPSPACE_grant_table so that they map the grant table somewhere in
the p2m.

My comment was the other way around: you can ditch the
GNTTABOP_setup_table call, but you need to keep the
XENMAPSPACE_grant_table one.

>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
> @@ -3324,6 +3422,9 @@ do_grant_table_op(
>      if ( (cmd &= GNTTABOP_CMD_MASK) != GNTTABOP_cache_flush && opaque_in )
>          return -EINVAL;
>  
> +    if ( is_vixen() )
> +        return vixen_do_grant_table_op(cmd, uop, count);

You seem to be missing the compat code.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 17/23] vixen: setup infrastructure to receive event channel notifications

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

This patch registers an interrupt handler using either an INTx
interrupt from the platform PCI device, CALLBACK_IRQ vector
delivery, or evtchn_upcall_vector depending on what the parent
hypervisor supports.

The event channel polling code comes from Linux but uses the
internal infrastructure for delivery.

Finally, this infrastructure has to be initialized per-VCPU so
hook the appropriate place for that.

Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - coding style
 - introduce #defines for the PCI vendor and device id
 - initialize grant table memory space
---
 xen/arch/x86/domain.c             |   3 +
 xen/arch/x86/guest/vixen.c        | 302 ++++++++++++++++++++++++++++++++++++++
 xen/arch/x86/setup.c              |   3 +
 xen/include/asm-x86/guest/vixen.h |   6 +
 xen/include/xen/pci_ids.h         |   2 +
 5 files changed, 316 insertions(+)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index da1bf1a..3e9c5be 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1147,6 +1147,9 @@ int arch_set_info_guest(
 
     update_cr3(v);
 
+    if ( is_vixen() )
+        vixen_vcpu_initialize(v);
+
  out:
     if ( flags & VGCF_online )
         clear_bit(_VPF_down, &v->pause_flags);
diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index 2437c92..59faa0c 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -23,6 +23,9 @@
 #include <public/version.h>
 #include <public/hvm/hvm_info_table.h>
 #include <xen/grant_table.h>
+#include <xen/event.h>
+#include <asm/apic.h>
+#include <xen/pci_ids.h>
 
 #define PCI_DEVICE_ID_XENSOURCE_PLATFORM	0x0001
 
@@ -36,6 +39,10 @@ static int vixen_domid = 1;
 static uint32_t vixen_reserved_mem_pgstart = 0xfeff0000;
 static shared_info_t *global_si;
 static bool vixen_ptver;
+static bool vixen_per_cpu_notifications = true;
+static uint8_t vixen_evtchn_vector;
+static bool vixen_needs_apic_ack = true;
+struct irqaction vixen_irqaction;
 
 integer_param("vixen_domid", vixen_domid);
 boolean_param("vixen_ptver", vixen_ptver);
@@ -153,3 +160,298 @@ bool vixen_passthru_version(void)
 {
     return is_vixen() && vixen_ptver;
 }
+
+/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+/* Find the first set bit in a evtchn mask */
+#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_XEN_ULONG)
+
+/*
+ * Mask out the i least significant bits of w
+ */
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
+
+static DEFINE_PER_CPU(unsigned int, current_word_idx);
+static DEFINE_PER_CPU(unsigned int, current_bit_idx);
+
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+                                         shared_info_t *sh,
+                                         unsigned int idx)
+{
+    return sh->native.evtchn_pending[idx] &
+           ~sh->native.evtchn_mask[idx];
+}
+
+static void vixen_evtchn_poll_one(size_t cpu)
+{
+    shared_info_t *s = global_si;
+    struct vcpu_info *vcpu_info = &s->native.vcpu_info[cpu];
+    xen_ulong_t pending_words;
+    xen_ulong_t pending_bits;
+    int start_word_idx, start_bit_idx;
+    int word_idx, bit_idx, i;
+
+    /*
+     * Master flag must be cleared /before/ clearing
+     * selector flag. xchg_xen_ulong must contain an
+     * appropriate barrier.
+     */
+    pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+
+    start_word_idx = this_cpu(current_word_idx);
+    start_bit_idx = this_cpu(current_bit_idx);
+
+    word_idx = start_word_idx;
+
+    for ( i = 0; pending_words != 0; i++ )
+    {
+        xen_ulong_t words;
+
+        words = MASK_LSBS(pending_words, word_idx);
+
+        /*
+         * If we masked out all events, wrap to beginning.
+         */
+        if ( words == 0 )
+        {
+            word_idx = 0;
+            bit_idx = 0;
+            continue;
+        }
+        word_idx = EVTCHN_FIRST_BIT(words);
+
+        pending_bits = active_evtchns(cpu, s, word_idx);
+        bit_idx = 0; /* usually scan entire word from start */
+        /*
+         * We scan the starting word in two parts.
+         *
+         * 1st time: start in the middle, scanning the
+         * upper bits.
+         *
+         * 2nd time: scan the whole word (not just the
+         * parts skipped in the first pass) -- if an
+         * event in the previously scanned bits is
+         * pending again it would just be scanned on
+         * the next loop anyway.
+         */
+        if ( word_idx == start_word_idx )
+        {
+            if ( i == 0 )
+                bit_idx = start_bit_idx;
+        }
+
+        do
+        {
+            struct evtchn *chn;
+            xen_ulong_t bits;
+            int port;
+
+            bits = MASK_LSBS(pending_bits, bit_idx);
+
+            /* If we masked out all events, move on. */
+            if ( bits == 0 )
+                break;
+
+            bit_idx = EVTCHN_FIRST_BIT(bits);
+
+            /* Process port. */
+            port = (word_idx * BITS_PER_XEN_ULONG) + bit_idx;
+
+            chn = evtchn_from_port(hardware_domain, port);
+            clear_bit(port, s->native.evtchn_pending);
+            evtchn_port_set_pending(hardware_domain, chn->notify_vcpu_id, chn);
+
+            bit_idx = (bit_idx + 1) % BITS_PER_XEN_ULONG;
+
+            /* Next caller starts at last processed + 1 */
+            this_cpu(current_word_idx) = bit_idx ? word_idx : (word_idx+1) % BITS_PER_XEN_ULONG;
+            this_cpu(current_bit_idx) = bit_idx;
+        } while ( bit_idx != 0 );
+
+        /* Scan start_l1i twice; all others once. */
+        if ( (word_idx != start_word_idx) || (i != 0) )
+            pending_words &= ~(1UL << word_idx);
+
+        word_idx = (word_idx + 1) % BITS_PER_XEN_ULONG;
+    }
+}
+
+static void vixen_upcall(int cpu)
+{
+    shared_info_t *s = global_si;
+    struct vcpu_info *vcpu_info = &s->native.vcpu_info[cpu];
+
+    do
+    {
+        vcpu_info->evtchn_upcall_pending = 0;
+        vixen_evtchn_poll_one(cpu);
+    } while ( vcpu_info->evtchn_upcall_pending );
+}
+
+static void vixen_evtchn_notify(struct cpu_user_regs *regs)
+{
+    if ( vixen_needs_apic_ack )
+        ack_APIC_irq();
+
+    vixen_upcall(smp_processor_id());
+}
+
+static void vixen_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
+{
+    vixen_upcall(smp_processor_id());
+}
+
+static int hvm_set_parameter(int idx, uint64_t value)
+{
+    struct xen_hvm_param xhv;
+    int r;
+
+    xhv.domid = DOMID_SELF;
+    xhv.index = idx;
+    xhv.value = value;
+    r = HYPERVISOR_hvm_op(HVMOP_set_param, &xhv);
+    if ( r < 0 ) {
+        printk("Cannot set hvm parameter %d: %d!\n",
+               idx, r);
+        return r;
+    }
+    return r;
+}
+
+void vixen_vcpu_initialize(struct vcpu *v)
+{
+    struct xen_hvm_evtchn_upcall_vector upcall;
+    long rc;
+
+    printk("VIXEN vcpu init VCPU%d\n", v->vcpu_id);
+
+    vcpu_pin_override(v, v->vcpu_id);
+
+    if ( !vixen_needs_apic_ack )
+        return;
+
+    printk("VIXEN vcpu init VCPU%d -- trying evtchn_upcall_vector\n", v->vcpu_id);
+
+    upcall.vcpu = v->vcpu_id;
+    upcall.vector = vixen_evtchn_vector;
+    rc = HYPERVISOR_hvm_op(HVMOP_set_evtchn_upcall_vector, &upcall);
+    if ( rc )
+    {
+        struct xen_feature_info fi;
+
+        printk("VIXEN vcpu init VCPU%d -- trying hvm_callback_vector\n", v->vcpu_id);
+
+        fi.submap_idx = 0;
+        rc = HYPERVISOR_xen_version(XENVER_get_features, &fi);
+        if ( !rc )
+        {
+            rc = -EINVAL;
+            if ( fi.submap & (1 << XENFEAT_hvm_callback_vector) )
+            {
+                rc = hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ,
+                                       ((uint64_t)HVM_PARAM_CALLBACK_TYPE_VECTOR << 56) | vixen_evtchn_vector);
+            }
+            if ( !rc )
+                vixen_needs_apic_ack = false;
+        }
+    }
+
+    if ( rc )
+    {
+        int slot;
+
+        vixen_per_cpu_notifications = false;
+
+        printk("VIXEN vcpu init VCPU%d -- trying pci_intx_callback\n", v->vcpu_id);
+        for ( slot = 2; slot < 32; slot++ )
+        {
+            uint16_t vendor, device;
+
+            vendor = pci_conf_read16(0, 0, slot, 0, PCI_VENDOR_ID);
+            device = pci_conf_read16(0, 0, slot, 0, PCI_DEVICE_ID);
+
+            if ( vendor == PCI_VENDOR_ID_XENSOURCE &&
+		 device == PCI_DEVICE_ID_XENSOURCE_PLATFORM )
+            {
+                break;
+            }
+        }
+
+        if ( slot != 32 )
+        {
+            int pin, line;
+
+            printk("Found Xen platform device at 0000:00:%02d.0\n", slot);
+            pin = pci_conf_read8(0, 0, slot, 0, PCI_INTERRUPT_PIN);
+            if ( pin )
+            {
+                line = pci_conf_read8(0, 0, slot, 0, PCI_INTERRUPT_LINE);
+                rc = hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ,
+                                       (1ULL << 56) | (slot << 11) | (pin - 1));
+
+                if ( rc )
+                {
+                    printk("Failed to setup IRQ callback\n");
+                }
+                else
+                {
+                    vixen_irqaction.handler = vixen_interrupt;
+                    vixen_irqaction.name = "vixen";
+                    vixen_irqaction.dev_id = 0;
+                    rc = setup_irq(line, 0, &vixen_irqaction);
+                    if ( rc )
+                    {
+                        printk("Setup IRQ failed!\n");
+                    }
+                    else
+                    {
+                        printk("Xen platform LNK mapped to line %d\n", line);
+                        vixen_needs_apic_ack = false;
+                    }
+                }
+            }
+        }
+        else
+        {
+            printk("Cannot find Platform device\n");
+        }
+    }
+}
+
+bool vixen_has_per_cpu_notifications(void)
+{
+    return vixen_per_cpu_notifications;
+}
+
+void __init
+vixen_transform(struct domain *dom0)
+{
+    struct xen_add_to_physmap xatp;
+    int i;
+
+    /* Setup event channel forwarding */
+    alloc_direct_apic_vector(&vixen_evtchn_vector, vixen_evtchn_notify);
+    printk("Vixen evtchn vector is %d\n", vixen_evtchn_vector);
+
+    /* Initialize the first vCPU */
+    vixen_vcpu_initialize(dom0->vcpu[0]);
+
+    /* Initialize grant table space */
+    BUG_ON((GRANT_TABLE_PFN_0 + gnttab_dom0_frames()) >= 0x100000);
+
+    for ( i = 0; i < gnttab_dom0_frames(); i++ )
+    {
+	xatp.domid = DOMID_SELF;
+	xatp.idx = i;
+	xatp.space = XENMAPSPACE_grant_table;
+	xatp.gpfn = GRANT_TABLE_PFN_0 + i;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if ( rc != 0 )
+	    printk("Add to physmap failed! %ld\n", rc);
+	
+	share_xen_page_with_guest(mfn_to_page(xatp.gpfn), dom0, XENSHARE_writable);
+    }
+}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 07239c0..1b89844 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1603,6 +1603,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     dom0->is_privileged = 1;
     dom0->target = NULL;
 
+    if ( is_vixen() )
+        vixen_transform(dom0);
+
     /* Grab the DOM0 command line. */
     cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
     if ( (cmdline != NULL) || (kextra != NULL) )
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index fbbc62c..140645c 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -82,4 +82,10 @@ u64 vixen_get_cpu_freq(void);
 
 bool vixen_passthru_version(void);
 
+bool vixen_has_per_cpu_notifications(void);
+
+void vixen_vcpu_initialize(struct vcpu *v);
+
+void __init vixen_transform(struct domain *dom0);
+
 #endif
diff --git a/xen/include/xen/pci_ids.h b/xen/include/xen/pci_ids.h
index 7788ba9..0003f01 100644
--- a/xen/include/xen/pci_ids.h
+++ b/xen/include/xen/pci_ids.h
@@ -9,3 +9,5 @@
 #define PCI_VENDOR_ID_BROADCOM           0x14e4
 
 #define PCI_VENDOR_ID_INTEL              0x8086
+
+#define PCI_VENDOR_ID_XENSOURCE          0x5853
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 18/23] vixen: Introduce ECS_PROXY for event channel proxying

[Anthony Liguori]

From: Jan H. Schönherr <jschoenh@amazon.de>

Previously, we would keep proxied event channels as ECS_INTERDOMAIN
channel around. This works for most things, but has the problem
that EVTCHNOP_status is broken, and that EVTCHNOP_close does not
mark an event channel as free.

Introduce a separate ECS_PROXY to denote event channels that are
forwarded to the hypervisor we're running under.

This makes the code more readable in many places.

Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/common/event_channel.c | 87 ++++++++++++++++++++++++++++++++++++++++------
 xen/include/xen/event.h    |  3 ++
 xen/include/xen/sched.h    |  1 +
 3 files changed, 81 insertions(+), 10 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c69f9db..85ff7e0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -30,6 +30,7 @@
 #include <public/xen.h>
 #include <public/event_channel.h>
 #include <xsm/xsm.h>
+#include <asm/guest/vixen.h>
 
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
@@ -156,25 +157,25 @@ static void free_evtchn_bucket(struct domain *d, struct evtchn *bucket)
     xfree(bucket);
 }
 
-static int get_free_port(struct domain *d)
+static int allocate_port(struct domain *d, int port)
 {
     struct evtchn *chn;
     struct evtchn **grp;
-    int            port;
 
     if ( d->is_dying )
         return -EINVAL;
 
-    for ( port = 0; port_is_valid(d, port); port++ )
+    if ( port_is_valid(d, port) )
     {
         if ( port > d->max_evtchn_port )
             return -ENOSPC;
         if ( evtchn_from_port(d, port)->state == ECS_FREE
              && !evtchn_port_is_busy(d, port) )
             return port;
+        return -EINVAL;
     }
 
-    if ( port == d->max_evtchns || port > d->max_evtchn_port )
+    if ( port >= d->max_evtchns || port > d->max_evtchn_port )
         return -ENOSPC;
 
     if ( !group_from_port(d, port) )
@@ -185,16 +186,59 @@ static int get_free_port(struct domain *d)
         group_from_port(d, port) = grp;
     }
 
-    chn = alloc_evtchn_bucket(d, port);
-    if ( !chn )
-        return -ENOMEM;
-    bucket_from_port(d, port) = chn;
+    while ( d->valid_evtchns <= port )
+    {
+        chn = alloc_evtchn_bucket(d, d->valid_evtchns);
+        if ( !chn )
+            return -ENOMEM;
+        bucket_from_port(d, d->valid_evtchns) = chn;
 
-    write_atomic(&d->valid_evtchns, d->valid_evtchns + EVTCHNS_PER_BUCKET);
+        write_atomic(&d->valid_evtchns, d->valid_evtchns + EVTCHNS_PER_BUCKET);
+    }
 
     return port;
 }
 
+static int get_free_port(struct domain *d)
+{
+    int port;
+
+    for ( port = 0; port_is_valid(d, port); port++ )
+    {
+        if ( port > d->max_evtchn_port )
+            return -ENOSPC;
+        if ( evtchn_from_port(d, port)->state == ECS_FREE
+             && !evtchn_port_is_busy(d, port) )
+            break;
+    }
+
+    return allocate_port(d, port);
+}
+
+int evtchn_alloc_proxy(struct domain *d, int port, u8 ecs)
+{
+    struct evtchn *chn;
+    int rc;
+
+    if ( !is_vixen() )
+        return -ENOSYS;
+
+    rc = allocate_port(d, port);
+    if ( rc < 0 )
+        return rc;
+
+    chn = evtchn_from_port(d, port);
+    spin_lock(&chn->lock);
+    chn->state = ECS_PROXY;
+    evtchn_port_init(d, chn);
+
+    if ( ecs == ECS_INTERDOMAIN )
+        evtchn_port_set_pending(d, chn->notify_vcpu_id, chn);
+    spin_unlock(&chn->lock);
+
+    return 0;
+}
+
 static void free_evtchn(struct domain *d, struct evtchn *chn)
 {
     /* Clear pending event to avoid unexpected behavior on re-bind. */
@@ -628,6 +672,9 @@ static long evtchn_close(struct domain *d1, int port1, bool_t guest)
 
         goto out;
 
+    case ECS_PROXY:
+        break;
+
     default:
         BUG();
     }
@@ -690,6 +737,14 @@ int evtchn_send(struct domain *ld, unsigned int lport)
     case ECS_UNBOUND:
         /* silently drop the notification */
         break;
+    case ECS_PROXY:
+        ret = -EINVAL;
+        if ( is_vixen() )
+        {
+            struct evtchn_send send = { .port = lport };
+            ret = HYPERVISOR_event_channel_op(EVTCHNOP_send, &send);
+        }
+        break;
     default:
         ret = -EINVAL;
     }
@@ -892,6 +947,10 @@ static long evtchn_status(evtchn_status_t *status)
     case ECS_IPI:
         status->status = EVTCHNSTAT_ipi;
         break;
+    case ECS_PROXY:
+        BUG_ON(!is_vixen());
+        rc = HYPERVISOR_event_channel_op(EVTCHNOP_status, status);
+        break;
     default:
         BUG();
     }
@@ -944,6 +1003,14 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id)
     case ECS_INTERDOMAIN:
         chn->notify_vcpu_id = vcpu_id;
         break;
+    case ECS_PROXY:
+        if ( is_vixen() && vixen_has_per_cpu_notifications() )
+        {
+            struct evtchn_bind_vcpu bind = { .port = port, .vcpu = vcpu_id };
+            HYPERVISOR_event_channel_op(EVTCHNOP_bind_vcpu, &bind);
+        }
+        chn->notify_vcpu_id = vcpu_id;
+        break;
     case ECS_PIRQ:
         if ( chn->notify_vcpu_id == vcpu_id )
             break;
@@ -1276,7 +1343,7 @@ int evtchn_init(struct domain *d)
     d->valid_evtchns = EVTCHNS_PER_BUCKET;
 
     spin_lock_init_prof(d, event_lock);
-    if ( get_free_port(d) != 0 )
+    if ( allocate_port(d, 0) != 0 )
     {
         free_evtchn_bucket(d, d->evtchn);
         return -EINVAL;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 87915ea..f3febe6 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -71,6 +71,9 @@ void notify_via_xen_event_channel(struct domain *ld, int lport);
 /* Inject an event channel notification into the guest */
 void arch_evtchn_inject(struct vcpu *v);
 
+/* Allocate a specific event channel as proxy. */
+int evtchn_alloc_proxy(struct domain *d, int port, u8 ecs);
+
 /*
  * Internal event channel object storage.
  *
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 5ddf6a2..f0a773b 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -93,6 +93,7 @@ struct evtchn
 #define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
 #define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
 #define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
+#define ECS_PROXY        7 /* Channel is proxied to parent hypervisor.       */
     u8  state;             /* ECS_* */
     u8  xen_consumer:XEN_CONSUMER_BITS; /* Consumer in Xen if nonzero */
     u8  pending:1;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 19/23] vixen: Fix Vixen adaptation of send_global_virq()

[Anthony Liguori]

From: Jan H. Schönherr <jschoenh@amazon.de>

The function originally did the following unconditionally:

   send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);

The new variant should reflect the non-Vixen case correctly.

Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/common/event_channel.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 85ff7e0..3dee73b 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -840,7 +840,10 @@ void send_global_virq(uint32_t virq)
     ASSERT(virq < NR_VIRQS);
     ASSERT(virq_is_global(virq));
 
-    send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
+    if ( global_virq_handlers[virq] )
+        send_guest_global_virq(global_virq_handlers[virq], virq);
+    else if ( !is_vixen() )
+        send_guest_global_virq(hardware_domain, virq);
 }
 
 int set_global_virq_handler(struct domain *d, uint32_t virq)
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 20/23] vixen: event channel passthrough support

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

For Vixen, we do not want to pass through all event channel
operations as HVM guests do not have nearly as many event channel
interactions as PV and on older versions of Xen, there is no reliable
way to wake up an event channel on VCPU != 0 leading to a variety of
deadlocks.

By only forwarding interdomain and unbound event channel operations,
we can avoid this problem since these can always be bound to VCPU 0
on older versions of Xen HVM.  On newer versions of Xen, we allow the
event channels to be bound to the VCPU requested by the inner guest.

To ensure that we keep everything in sync, all event channels end up
allocating an unbound event channel in the parent Xen and we rely on
the parent Xen to owner the event channel address space.

Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/common/event_channel.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 3dee73b..54ea720 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -199,10 +199,34 @@ static int allocate_port(struct domain *d, int port)
     return port;
 }
 
+static int vixen_get_free_port(struct domain *d)
+{
+    int rc;
+    struct evtchn_alloc_unbound unbound = { .dom = DOMID_SELF,
+                                            .remote_dom = DOMID_SELF };
+
+    rc = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &unbound);
+    if ( rc )
+        return rc;
+
+    rc = allocate_port(d, unbound.port);
+    if ( rc < 0 )
+    {
+        struct evtchn_close close = { .port = unbound.port };
+        HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
+        printk("Vixen: failed to allocate event channel %d => %d\n",
+               unbound.port, rc);
+    }
+    return rc;
+}
+
 static int get_free_port(struct domain *d)
 {
     int port;
 
+    if ( is_vixen() )
+        return vixen_get_free_port(d);
+
     for ( port = 0; port_is_valid(d, port); port++ )
     {
         if ( port > d->max_evtchn_port )
@@ -252,6 +276,11 @@ static void free_evtchn(struct domain *d, struct evtchn *chn)
     xsm_evtchn_close_post(chn);
 }
 
+static bool is_loopback(domid_t ldom, domid_t rdom)
+{
+    return ldom == DOMID_SELF && rdom == DOMID_SELF;
+}
+
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
     struct evtchn *chn;
@@ -266,6 +295,23 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 
     spin_lock(&d->event_lock);
 
+    if ( is_vixen() && !is_loopback(alloc->dom, alloc->remote_dom) ) {
+        rc = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, alloc);
+        if ( rc )
+            goto out;
+
+        rc = evtchn_alloc_proxy(d, alloc->port, ECS_UNBOUND);
+        if ( rc )
+        {
+            struct evtchn_close close = { .port = alloc->port };
+            HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
+            printk("Vixen: failed to reserve unbound event channel %d => %ld\n",
+                   alloc->port, rc);
+        }
+
+        goto out;
+    }
+
     if ( (port = get_free_port(d)) < 0 )
         ERROR_EXIT_DOM(port, d);
     chn = evtchn_from_port(d, port);
@@ -315,6 +361,27 @@ static void double_evtchn_unlock(struct evtchn *lchn, struct evtchn *rchn)
         spin_unlock(&rchn->lock);
 }
 
+static long vixen_evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
+{
+    struct domain *d = current->domain;
+    long rc;
+
+    rc = HYPERVISOR_event_channel_op(EVTCHNOP_bind_interdomain, bind);
+    if ( rc )
+        return rc;
+
+    rc = evtchn_alloc_proxy(d, bind->local_port, ECS_INTERDOMAIN);
+    if ( rc )
+    {
+        struct evtchn_close close = { .port = bind->local_port };
+        HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
+        printk("Vixen: failed to reserve inter-domain event channel %d => %ld\n",
+               bind->local_port, rc);
+    }
+
+    return rc;
+}
+
 static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
 {
     struct evtchn *lchn, *rchn;
@@ -323,6 +390,9 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
     domid_t        rdom = bind->remote_dom;
     long           rc;
 
+    if ( is_vixen() && !is_loopback(DOMID_SELF, bind->remote_dom) )
+        return vixen_evtchn_bind_interdomain(bind);
+
     if ( rdom == DOMID_SELF )
         rdom = current->domain->domain_id;
 
@@ -581,6 +651,13 @@ static long evtchn_close(struct domain *d1, int port1, bool_t guest)
         goto out;
     }
 
+    if ( is_vixen() ) {
+        struct evtchn_close close = { .port = port1 };
+        rc = HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
+        if (rc != 0)
+            goto out;
+    }
+
     switch ( chn1->state )
     {
     case ECS_FREE:
@@ -1215,6 +1292,10 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     case EVTCHNOP_init_control: {
         struct evtchn_init_control init_control;
+
+        if ( is_vixen() )
+            return -ENOSYS;
+
         if ( copy_from_guest(&init_control, arg, 1) != 0 )
             return -EFAULT;
         rc = evtchn_fifo_init_control(&init_control);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 21/23] vixen: provide Xencons implementation

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

Our initial approach exposed the console ring directly to guests
which worked well except for the fact that very old versions of Xen
did not support console ring for HVM guests.  It also proved to
be complicated from a management tool perspective since both the
serial console and the paravirt console for HVM guests produced
output.

Having a simple xencons implementation helps simplify using Vixen
as a management tool no longer needs to care about whether or not
this mode is enabled.

In order to output to the console without the '(Xen)' adornment,
we introduce a new entry point into the console code too.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
 xen/arch/x86/guest/vixen.c        | 41 +++++++++++++++++++++++++++++++++++++++
 xen/common/event_channel.c        |  5 ++++-
 xen/drivers/char/console.c        | 16 +++++++++++++++
 xen/include/asm-x86/guest/vixen.h |  2 ++
 xen/include/xen/lib.h             |  1 +
 5 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index 59faa0c..d871218 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -26,6 +26,7 @@
 #include <xen/event.h>
 #include <asm/apic.h>
 #include <xen/pci_ids.h>
+#include <public/io/console.h>
 
 #define PCI_DEVICE_ID_XENSOURCE_PLATFORM	0x0001
 
@@ -43,6 +44,9 @@ static bool vixen_per_cpu_notifications = true;
 static uint8_t vixen_evtchn_vector;
 static bool vixen_needs_apic_ack = true;
 struct irqaction vixen_irqaction;
+static volatile struct xencons_interface *vixen_xencons_iface;
+static uint16_t vixen_xencons_port;
+static spinlock_t vixen_xencons_lock;
 
 integer_param("vixen_domid", vixen_domid);
 boolean_param("vixen_ptver", vixen_ptver);
@@ -89,6 +93,8 @@ void __init init_vixen(void)
 	}
     }
 
+    spin_lock_init(&vixen_xencons_lock);
+
     in_vixen = 1;
 }
 
@@ -304,6 +310,41 @@ static void vixen_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
     vixen_upcall(smp_processor_id());
 }
 
+bool vixen_ring_process(uint16_t port)
+{
+    volatile struct xencons_interface *r = vixen_xencons_iface;
+    char buffer[128];
+    size_t n;
+
+    if (r == NULL || port != vixen_xencons_port) {
+        return false;
+    }
+
+    spin_lock(&vixen_xencons_lock);
+
+    n = 0;
+    while (r->out_prod != r->out_cons) {
+        char ch = r->out[MASK_XENCONS_IDX(r->out_cons, r->out)];
+        if (n == sizeof(buffer) - 1) {
+            buffer[n] = 0;
+            guest_puts(hardware_domain, buffer);
+            n = 0;
+        }
+        buffer[n++] = ch;
+        rmb();
+        r->out_cons++;
+    }
+
+    if (n) {
+        buffer[n] = 0;
+        guest_puts(hardware_domain, buffer);
+    }
+
+    spin_unlock(&vixen_xencons_lock);
+
+    return true;
+}
+
 static int hvm_set_parameter(int idx, uint64_t value)
 {
     struct xen_hvm_param xhv;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 54ea720..6d060a5 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1241,7 +1241,10 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         struct evtchn_send send;
         if ( copy_from_guest(&send, arg, 1) != 0 )
             return -EFAULT;
-        rc = evtchn_send(current->domain, send.port);
+        if ( vixen_ring_process(send.port) )
+            rc = 0;
+        else
+            rc = evtchn_send(current->domain, send.port);
         break;
     }
 
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 3eb130d..4be34d4 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -775,6 +775,22 @@ void guest_printk(const struct domain *d, const char *fmt, ...)
     va_end(args);
 }
 
+void guest_puts(const struct domain *d, const char *kbuf)
+{
+    spin_lock_irq(&console_lock);
+
+    sercon_puts(kbuf);
+    video_puts(kbuf);
+
+    if ( opt_console_to_ring )
+    {
+        conring_puts(kbuf);
+        tasklet_schedule(&notify_dom0_con_ring_tasklet);
+    }
+
+    spin_unlock_irq(&console_lock);
+}
+
 void __init console_init_preirq(void)
 {
     char *p;
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index 140645c..4b59cc7 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -88,4 +88,6 @@ void vixen_vcpu_initialize(struct vcpu *v);
 
 void __init vixen_transform(struct domain *dom0);
 
+bool vixen_ring_process(uint16_t port);
+
 #endif
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ed00ae1..de84638 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -92,6 +92,7 @@ extern void printk(const char *format, ...)
     __attribute__ ((format (printf, 1, 2)));
 extern void guest_printk(const struct domain *d, const char *format, ...)
     __attribute__ ((format (printf, 2, 3)));
+extern void guest_puts(const struct domain *d, const char *message);
 extern void noreturn panic(const char *format, ...)
     __attribute__ ((format (printf, 1, 2)));
 extern long vm_assist(struct domain *, unsigned int cmd, unsigned int type,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 22/23] vixen: dom0 builder support

[Anthony Liguori]

From: Anthony Liguori <aliguori@amazon.com>

The dom0 builder requires a number of modifications in order to be
able to launch unprivileged guests.  The console and store pages
must be mapped in a specific location within the guest's initial
page table.

We also have to setup the start info to be what's expected for
unprivileged guests and supress the normal logic to give dom0
increased permissions.

We have to pass around the console and store pages which involves
touching a number of places including the PVH builder.

Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - panic in the event of errors
---
 xen/arch/x86/dom0_build.c         |  7 +++-
 xen/arch/x86/guest/vixen.c        | 64 +++++++++++++++++++++++++++++++-
 xen/arch/x86/hvm/dom0_build.c     |  4 +-
 xen/arch/x86/pv/dom0_build.c      | 77 ++++++++++++++++++++++++++++++++++-----
 xen/arch/x86/setup.c              | 12 +++++-
 xen/include/asm-x86/dom0_build.h  |  8 +++-
 xen/include/asm-x86/guest/vixen.h |  5 ++-
 xen/include/asm-x86/setup.h       |  4 +-
 8 files changed, 161 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 88810db..df9d3f8 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -464,7 +464,9 @@ int __init dom0_setup_permissions(struct domain *d)
 int __init construct_dom0(struct domain *d, const module_t *image,
                           unsigned long image_headroom, module_t *initrd,
                           void *(*bootstrap_map)(const module_t *),
-                          char *cmdline)
+                          char *cmdline,
+                          xen_pfn_t store_mfn, uint32_t store_evtchn,
+                          xen_pfn_t console_mfn, uint32_t console_evtchn)
 {
     int rc;
 
@@ -484,7 +486,8 @@ int __init construct_dom0(struct domain *d, const module_t *image,
 #endif
 
     rc = (is_hvm_domain(d) ? dom0_construct_pvh : dom0_construct_pv)
-         (d, image, image_headroom, initrd, bootstrap_map, cmdline);
+         (d, image, image_headroom, initrd, bootstrap_map, cmdline,
+          store_mfn, store_evtchn, console_mfn, console_evtchn);
     if ( rc )
         return rc;
 
diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index d871218..7e367ef 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -345,6 +345,23 @@ bool vixen_ring_process(uint16_t port)
     return true;
 }
 
+static int hvm_get_parameter(int idx, uint64_t *value)
+{
+    struct xen_hvm_param xhv;
+    int r;
+
+    xhv.domid = DOMID_SELF;
+    xhv.index = idx;
+    r = HYPERVISOR_hvm_op(HVMOP_get_param, &xhv);
+    if (r < 0) {
+        printk("Cannot get hvm parameter %d: %d!\n",
+               idx, r);
+        return r;
+    }
+    *value = xhv.value;
+    return r;
+}
+
 static int hvm_set_parameter(int idx, uint64_t value)
 {
     struct xen_hvm_param xhv;
@@ -468,10 +485,55 @@ bool vixen_has_per_cpu_notifications(void)
 }
 
 void __init
-vixen_transform(struct domain *dom0)
+vixen_transform(struct domain *dom0,
+                xen_pfn_t *pstore_mfn, uint32_t *pstore_evtchn,
+                xen_pfn_t *pconsole_mfn, uint32_t *pconsole_evtchn)
 {
     struct xen_add_to_physmap xatp;
     int i;
+    uint64_t v = 0;
+    long rc;
+    struct evtchn_unmask unmask;
+    struct evtchn_alloc_unbound alloc;
+
+    /* Setup Xenstore */
+    hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+    *pstore_evtchn = unmask.port = v;
+    HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
+
+    hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
+    *pstore_mfn = v;
+
+    printk("Vixen Xenstore evtchn is %d, pfn is 0x%" PRIx64 "\n",
+           *pstore_evtchn, *pstore_mfn);
+
+    /* Setup Xencons */
+    alloc.dom = DOMID_SELF;
+    alloc.remote_dom = DOMID_SELF;
+
+    rc = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &alloc);
+    if ( rc )
+    {
+        printk("Failed to alloc unbound event channel: %ld\n", rc);
+        *pconsole_evtchn = 0;
+        *pconsole_mfn = 0;
+    }
+    else
+    {
+        void *console_data;
+
+        console_data = alloc_xenheap_page();
+
+        *pconsole_evtchn = alloc.port;
+        *pconsole_mfn = virt_to_mfn(console_data);
+
+        memset(console_data, 0, 4096);
+        vixen_xencons_iface = console_data;
+        vixen_xencons_port = alloc.port;
+    }
+
+    printk("Vixen Xencons evtchn is %d, pfn is 0x%" PRIx64 "\n",
+           *pconsole_evtchn, *pconsole_mfn);
 
     /* Setup event channel forwarding */
     alloc_direct_apic_vector(&vixen_evtchn_vector, vixen_evtchn_notify);
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 4338965..b2ca64f 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1064,7 +1064,9 @@ int __init dom0_construct_pvh(struct domain *d, const module_t *image,
                               unsigned long image_headroom,
                               module_t *initrd,
                               void *(*bootstrap_map)(const module_t *),
-                              char *cmdline)
+                              char *cmdline,
+                              xen_pfn_t store_mfn, uint32_t store_evtchn,
+                              xen_pfn_t console_mfn, uint32_t console_evtchn)
 {
     paddr_t entry, start_info;
     int rc;
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 09c765a..a554629 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -7,6 +7,7 @@
 #include <xen/console.h>
 #include <xen/domain.h>
 #include <xen/domain_page.h>
+#include <xen/event.h>
 #include <xen/init.h>
 #include <xen/libelf.h>
 #include <xen/multiboot.h>
@@ -276,7 +277,9 @@ int __init dom0_construct_pv(struct domain *d,
                              unsigned long image_headroom,
                              module_t *initrd,
                              void *(*bootstrap_map)(const module_t *),
-                             char *cmdline)
+                             char *cmdline,
+                             xen_pfn_t store_mfn, uint32_t store_evtchn,
+                             xen_pfn_t console_mfn, uint32_t console_evtchn)
 {
     int i, cpu, rc, compatible, compat32, order, machine;
     struct cpu_user_regs *regs;
@@ -299,6 +302,7 @@ int __init dom0_construct_pv(struct domain *d,
     l3_pgentry_t *l3tab = NULL, *l3start = NULL;
     l2_pgentry_t *l2tab = NULL, *l2start = NULL;
     l1_pgentry_t *l1tab = NULL, *l1start = NULL;
+    xen_pfn_t saved_pfn = ~0UL;
 
     /*
      * This fully describes the memory layout of the initial domain. All
@@ -441,8 +445,24 @@ int __init dom0_construct_pv(struct domain *d,
         vphysmap_end = vphysmap_start;
     vstartinfo_start = round_pgup(vphysmap_end);
     vstartinfo_end   = (vstartinfo_start +
-                        sizeof(struct start_info) +
-                        sizeof(struct dom0_vga_console_info));
+                        sizeof(struct start_info));
+    if ( !is_vixen() )
+        vstartinfo_end += sizeof(struct dom0_vga_console_info);
+    vstartinfo_end   = round_pgup(vstartinfo_end);
+
+    if ( is_vixen() ) {
+        struct page_info *pg;
+
+        saved_pfn = (vstartinfo_end - v_start) / PAGE_SIZE;
+
+        pg = mfn_to_page(store_mfn);
+        share_xen_page_with_guest(pg, d, XENSHARE_writable);
+        vstartinfo_end   += PAGE_SIZE;
+
+        pg = mfn_to_page(console_mfn);
+        share_xen_page_with_guest(pg, d, XENSHARE_writable);
+        vstartinfo_end   += PAGE_SIZE;
+    }
 
     vpt_start        = round_pgup(vstartinfo_end);
     for ( nr_pt_pages = 2; ; nr_pt_pages++ )
@@ -634,7 +654,13 @@ int __init dom0_construct_pv(struct domain *d,
             *l2tab = l2e_from_paddr(__pa(l1start), L2_PROT);
             l2tab++;
         }
-        if ( count < initrd_pfn || count >= initrd_pfn + PFN_UP(initrd_len) )
+        if ( count == saved_pfn ) {
+            mfn = store_mfn;
+            pfn++;
+        } else if ( count == saved_pfn + 1 ) {
+            mfn = console_mfn;
+            pfn++;
+        } else if ( count < initrd_pfn || count >= initrd_pfn + PFN_UP(initrd_len) )
             mfn = pfn++;
         else
             mfn = initrd_mfn++;
@@ -737,7 +763,8 @@ int __init dom0_construct_pv(struct domain *d,
 
     si->shared_info = virt_to_maddr(d->shared_info);
 
-    si->flags        = SIF_PRIVILEGED | SIF_INITDOMAIN;
+    si->flags        = is_vixen() ? 0 : (SIF_PRIVILEGED | SIF_INITDOMAIN);
+
     if ( !vinitrd_start && initrd_len )
         si->flags   |= SIF_MOD_START_PFN;
     si->flags       |= (xen_processor_pmbits << 8) & SIF_PM_MASK;
@@ -818,6 +845,30 @@ int __init dom0_construct_pv(struct domain *d,
         }
     }
 
+    if ( is_vixen() )
+    {
+        dom0_update_physmap(d, saved_pfn, store_mfn, vphysmap_start);
+        dom0_update_physmap(d, saved_pfn + 1, console_mfn, vphysmap_start);
+
+        rc = evtchn_alloc_proxy(d, store_evtchn, ECS_INTERDOMAIN);
+        if ( rc )
+        {
+            panic("Vixen: failed to reserve Xenstore event channel %d => %d\n",
+                  store_evtchn, rc);
+        }
+        rc = evtchn_alloc_proxy(d, console_evtchn, ECS_INTERDOMAIN);
+        if ( rc )
+        {
+            panic("Vixen: failed to reserve Console event channel %d => %d\n",
+                  console_evtchn, rc);
+        }
+
+        si->store_mfn = store_mfn;
+        si->store_evtchn = store_evtchn;
+        si->console.domU.mfn = console_mfn;
+        si->console.domU.evtchn = console_evtchn;
+    }
+
     if ( initrd_len != 0 )
     {
         si->mod_start = vinitrd_start ?: initrd_pfn;
@@ -828,14 +879,15 @@ int __init dom0_construct_pv(struct domain *d,
     if ( cmdline != NULL )
         strlcpy((char *)si->cmd_line, cmdline, sizeof(si->cmd_line));
 
-    if ( fill_console_start_info((void *)(si + 1)) )
+    if ( !is_vixen() && fill_console_start_info((void *)(si + 1)) )
     {
         si->console.dom0.info_off  = sizeof(struct start_info);
         si->console.dom0.info_size = sizeof(struct dom0_vga_console_info);
     }
 
     if ( is_pv_32bit_domain(d) )
-        xlat_start_info(si, XLAT_start_info_console_dom0);
+        xlat_start_info(si, is_vixen() ? XLAT_start_info_console_domU :
+                                         XLAT_start_info_console_dom0);
 
     /* Return to idle domain's page tables. */
     mapcache_override_current(NULL);
@@ -873,9 +925,11 @@ int __init dom0_construct_pv(struct domain *d,
     if ( test_bit(XENFEAT_supervisor_mode_kernel, parms.f_required) )
         panic("Dom0 requires supervisor-mode execution");
 
-    rc = dom0_setup_permissions(d);
-    BUG_ON(rc != 0);
-
+    if ( !is_vixen() )
+    {
+        rc = dom0_setup_permissions(d);
+        BUG_ON(rc != 0);
+    }
     if ( elf_check_broken(&elf) )
         printk(" Xen warning: dom0 kernel broken ELF: %s\n",
                elf_check_broken(&elf));
@@ -886,6 +940,9 @@ int __init dom0_construct_pv(struct domain *d,
     v->is_initialised = 1;
     clear_bit(_VPF_down, &v->pause_flags);
 
+    if ( is_vixen() )
+        d->max_pages = d->tot_pages;
+
     return 0;
 
 out:
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1b89844..c49eeea 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -663,6 +663,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         .stop_bits = 1
     };
     struct xen_arch_domainconfig config = { .emulation_flags = 0 };
+    xen_pfn_t store_mfn = 0, console_mfn = 0;
+    uint32_t store_evtchn = 0, console_evtchn = 0;
 
     /* Critical region without IDT or TSS.  Any fault is deadly! */
 
@@ -1595,6 +1597,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
         config.emulation_flags = XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC;
     }
 
+    if ( is_vixen() )
+        config.emulation_flags = XEN_X86_EMU_PIT;
+
     /* Create initial domain 0. */
     dom0 = domain_create(dom0_domid, domcr_flags, 0, &config);
     if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
@@ -1604,7 +1609,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     dom0->target = NULL;
 
     if ( is_vixen() )
-        vixen_transform(dom0);
+        vixen_transform(dom0, &store_mfn, &store_evtchn,
+                        &console_mfn, &console_evtchn);
 
     /* Grab the DOM0 command line. */
     cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
@@ -1667,7 +1673,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( construct_dom0(dom0, mod, modules_headroom,
                         (initrdidx > 0) && (initrdidx < mbi->mods_count)
                         ? mod + initrdidx : NULL,
-                        bootstrap_map, cmdline) != 0)
+                        bootstrap_map, cmdline,
+                        store_mfn, store_evtchn,
+                        console_mfn, console_evtchn) != 0)
         panic("Could not set up DOM0 guest OS");
 
     if ( cpu_has_smap )
diff --git a/xen/include/asm-x86/dom0_build.h b/xen/include/asm-x86/dom0_build.h
index d83d2b4..459211c 100644
--- a/xen/include/asm-x86/dom0_build.h
+++ b/xen/include/asm-x86/dom0_build.h
@@ -18,13 +18,17 @@ int dom0_construct_pv(struct domain *d, const module_t *image,
                       unsigned long image_headroom,
                       module_t *initrd,
                       void *(*bootstrap_map)(const module_t *),
-                      char *cmdline);
+                      char *cmdline,
+                      xen_pfn_t store_mfn, uint32_t store_evtchn,
+                      xen_pfn_t console_mfn, uint32_t console_evtchn);
 
 int dom0_construct_pvh(struct domain *d, const module_t *image,
                        unsigned long image_headroom,
                        module_t *initrd,
                        void *(*bootstrap_map)(const module_t *),
-                       char *cmdline);
+                       char *cmdline,
+                       xen_pfn_t store_mfn, uint32_t store_evtchn,
+                       xen_pfn_t console_mfn, uint32_t console_evtchn);
 
 unsigned long dom0_paging_pages(const struct domain *d,
                                 unsigned long nr_pages);
diff --git a/xen/include/asm-x86/guest/vixen.h b/xen/include/asm-x86/guest/vixen.h
index 4b59cc7..851281d 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -86,7 +86,10 @@ bool vixen_has_per_cpu_notifications(void);
 
 void vixen_vcpu_initialize(struct vcpu *v);
 
-void __init vixen_transform(struct domain *dom0);
+void __init
+vixen_transform(struct domain *dom0,
+                xen_pfn_t *pstore_mfn, uint32_t *pstore_evtchn,
+                xen_pfn_t *pconsole_mfn, uint32_t *pconsole_evtchn);
 
 bool vixen_ring_process(uint16_t port);
 
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index c5b3d4e..51b207b 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -39,7 +39,9 @@ int construct_dom0(
     const module_t *kernel, unsigned long kernel_headroom,
     module_t *initrd,
     void *(*bootstrap_map)(const module_t *),
-    char *cmdline);
+    char *cmdline,
+    xen_pfn_t store_mfn, uint32_t store_evtchn,
+    xen_pfn_t console_mfn, uint32_t console_evtchn);
 void setup_io_bitmap(struct domain *d);
 
 unsigned long initial_images_nrpages(nodeid_t node);
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 23/23] vixen: use default position for the m2p mappings

[Anthony Liguori]

From: Roger Pau Monne <roger.pau@citrix.com>

When running a 32bit kernel as Dom0 on a 64bit hypervisor the
hypervisor will try to shrink the hypervisor hole to the minimum
needed, and thus requires the Dom0 to use XENMEM_machphys_mapping in
order to fetch the position of the start of the hypervisor virtual
mappings.

Disable this feature when running as a PV shim, since some DomU
kernels don't implemented XENMEM_machphys_mapping and break if the m2p
doesn't begin at the default address.

NB: support for the XENMEM_machphys_mapping was added in Linux by
commit 7e7750.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
---
v1 -> v2
 - adapted for Vixen
---
 xen/arch/x86/pv/dom0_build.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index a554629..2bc6339 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -398,7 +398,8 @@ int __init dom0_construct_pv(struct domain *d,
     if ( parms.pae == XEN_PAE_EXTCR3 )
             set_bit(VMASST_TYPE_pae_extended_cr3, &d->vm_assist);
 
-    if ( (parms.virt_hv_start_low != UNSET_ADDR) && elf_32bit(&elf) )
+    if ( !is_vixen() && (parms.virt_hv_start_low != UNSET_ADDR) &&
+         elf_32bit(&elf) )
     {
         unsigned long mask = (1UL << L2_PAGETABLE_SHIFT) - 1;
         value = (parms.virt_hv_start_low + mask) & ~mask;
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 00/23] Vixen: A PV-in-HVM shim

[Wei Liu]

On Sun, Jan 07, 2018 at 12:28:16PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori <aliguori@amazon.com>
> 
> CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
> appears to be very difficult to isolate the hypervisor's page tables
> from PV domUs while maintaining ABI compatibility.  Instead of trying
> to make a KPTI-like approach work for Xen PV, it seems reasonable to
> run a copy of Xen within an HVM (or PVH) domU to provide backwards
> compatibility with guests as mentioned in XSA-254 [1].
> 
> This patch series adds a new mode to Xen called Vixen (Virtualized
> Xen) which provides a PV-compatible interface while gaining
> CVE-2017-5754 protection for the host provided by hardware
> virtualization.  Vixen supports running a single unprivileged PV
> domain (a dom1) that is constructed by the dom0 domain builder.
> 
> Please note the Xen page table configuration fundamental to the
> current PV ABI makes it impossible for an operating system to mitigate
> CVE-2017-5754 through mechanisms like Kernel Page Table Isolation
> (KPTI).  In order for an operating system to mitigate CVE-2017-5754 it
> must run directly in a HVM or PVH domU.
> 
> This series is very similar to the PVH series posted by Wei and we
> have been discussing how to merge efforts.  We were hoping to have
> more time to work this out.  I am posting this because I'm fairly
> confident that this series is complete (all PV instances in EC2 are
> using this) and others might find it useful.  I also wanted to have
> more of a discussion about the best way to merge and some of the
> differences in designs.
> 
> This series is also available at:
> 
>  git clone https://github.com/aliguori/xen.git vixen-upstream-v2

You have a typo in the name of the branch. It is vixen-upstrea-v2 on
github. :-)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 00/23] Vixen: A PV-in-HVM shim

[Anthony Liguori]

On Mon, Jan 8, 2018 at 9:13 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Sun, Jan 07, 2018 at 12:28:16PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori <aliguori@amazon.com>
>>
>> CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
>> appears to be very difficult to isolate the hypervisor's page tables
>> from PV domUs while maintaining ABI compatibility.  Instead of trying
>> to make a KPTI-like approach work for Xen PV, it seems reasonable to
>> run a copy of Xen within an HVM (or PVH) domU to provide backwards
>> compatibility with guests as mentioned in XSA-254 [1].
>>
>> This patch series adds a new mode to Xen called Vixen (Virtualized
>> Xen) which provides a PV-compatible interface while gaining
>> CVE-2017-5754 protection for the host provided by hardware
>> virtualization.  Vixen supports running a single unprivileged PV
>> domain (a dom1) that is constructed by the dom0 domain builder.
>>
>> Please note the Xen page table configuration fundamental to the
>> current PV ABI makes it impossible for an operating system to mitigate
>> CVE-2017-5754 through mechanisms like Kernel Page Table Isolation
>> (KPTI).  In order for an operating system to mitigate CVE-2017-5754 it
>> must run directly in a HVM or PVH domU.
>>
>> This series is very similar to the PVH series posted by Wei and we
>> have been discussing how to merge efforts.  We were hoping to have
>> more time to work this out.  I am posting this because I'm fairly
>> confident that this series is complete (all PV instances in EC2 are
>> using this) and others might find it useful.  I also wanted to have
>> more of a discussion about the best way to merge and some of the
>> differences in designs.
>>
>> This series is also available at:
>>
>>  git clone https://github.com/aliguori/xen.git vixen-upstream-v2
>
> You have a typo in the name of the branch. It is vixen-upstrea-v2 on
> github. :-)

Fixed :-D

Regards,

Anthony Liguori


> Wei.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel