[Xen-devel] [libvirt test] 124095: regressions - FAIL

[osstest service owner]

flight 124095 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124095/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  4e3a9daa6668051f1d8669e989ae7594c4e22619
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z7 days
Failing since123840  2018-06-06 04:19:28 Z6 days7 attempts
Testing same since   124095  2018-06-12 04:19:09 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Brijesh Singh 
  Chen Hanxiao 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Fabiano Fidêncio 
  Filip Alac 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Katerina Koukiou 
  Laszlo Ersek 
  Marc Hartmayer 
  Martin Kletzander 
  Michal Privoznik 
  Peter Krempa 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Roman Bogorodskiy 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at

[Xen-devel] [PATCH v3 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2

[Julien Grall]

The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
enabling/disabling the ssbd mitigation. So we want the handling to
be as fast as possible.

The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
also track the state of the workaround per-vCPU.

Note that since we need to execute branches, this always executes after
the spectre-v2 mitigation.

This code is based on KVM counterpart "arm64: KVM: Handle guest's
ARCH_WORKAROUND_2 requests" written by Marc Zyngier.

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v3:
- Add Stefano's reviewed-by

Changes in v2:
- Combine the 2 consecutive eor instructions in a single one.
---
 xen/arch/arm/arm64/asm-offsets.c |  2 ++
 xen/arch/arm/arm64/entry.S   | 42 +++-
 xen/arch/arm/cpuerrata.c | 18 +
 3 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index ce24e44473..f5c696d092 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -22,6 +22,7 @@
 void __dummy__(void)
 {
OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_X1, struct cpu_user_regs, x1);
OFFSET(UREGS_LR, struct cpu_user_regs, lr);
 
OFFSET(UREGS_SP, struct cpu_user_regs, sp);
@@ -45,6 +46,7 @@ void __dummy__(void)
BLANK();
 
DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+   OFFSET(CPUINFO_flags, struct cpu_info, flags);
 
OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
 
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index e2344e565f..97b05f53ea 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,4 +1,6 @@
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -241,7 +243,7 @@ guest_sync:
  * be encoded as an immediate for cmp.
  */
 eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
-cbnzw0, guest_sync_slowpath
+cbnzw0, check_wa2
 
 /*
  * Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,6 +252,44 @@ guest_sync:
 mov x1, xzr
 eret
 
+check_wa2:
+/* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
+eor w0, w0, #(ARM_SMCCC_ARCH_WORKAROUND_1_FID ^ 
ARM_SMCCC_ARCH_WORKAROUND_2_FID)
+cbnzw0, guest_sync_slowpath
+#ifdef CONFIG_ARM_SSBD
+alternative_cb arm_enable_wa2_handling
+b   wa2_end
+alternative_cb_end
+/* Sanitize the argument */
+mov x0, #-(UREGS_kernel_sizeof - UREGS_X1)  /* x0 := offset of 
guest's x1 on the stack */
+ldr x1, [sp, x0]/* Load guest's x1 */
+cmp w1, wzr
+csetx1, ne
+
+/*
+ * Update the guest flag. At this stage sp point after the field
+ * guest_cpu_user_regs in cpu_info.
+ */
+adr_cpu_info x2
+ldr x0, [x2, #CPUINFO_flags]
+bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
+str x0, [x2, #CPUINFO_flags]
+
+/* Check that we actually need to perform the call */
+ldr_this_cpu x0, ssbd_callback_required, x2
+cbz x0, wa2_end
+
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
+smc #0
+
+wa2_end:
+/* Don't leak data from the SMC call */
+mov x1, xzr
+mov x2, xzr
+mov x3, xzr
+#endif /* !CONFIG_ARM_SSBD */
+mov x0, xzr
+eret
 guest_sync_slowpath:
 /*
  * x0/x1 may have been scratch by the fast path above, so avoid
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 4292008692..7455f09f26 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
@@ -272,6 +273,23 @@ static int __init parse_spec_ctrl(const char *s)
 }
 custom_param("spec-ctrl", parse_spec_ctrl);
 
+/* Arm64 only for now as for Arm32 the workaround is currently handled in C. */
+#ifdef CONFIG_ARM_64
+void __init arm_enable_wa2_handling(const struct alt_instr *alt,
+const uint32_t *origptr,
+uint32_t *updptr, int nr_inst)
+{
+BUG_ON(nr_inst != 1);
+
+/*
+ * Only allow mitigation on guest ARCH_WORKAROUND_2 if the SSBD
+ * state allow it to be flipped.
+ */
+if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+*updptr = aarch64_insn_gen_nop();
+}
+#endif
+
 /*
  * Assembly code may use the variable directly, so we need to make sure
  * it fits in a register.
-- 
2.11.0


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

[Xen-devel] [PATCH v3 08/13] xen/arm: alternatives: Add dynamic patching feature

[Julien Grall]

This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
dynamic patching feature" written by Marc Zyngier:

We've so far relied on a patching infrastructure that only gave us
a single alternative, without any way to provide a range of potential
replacement instructions. For a single feature, this is an all or
nothing thing.

It would be interesting to have a more flexible grained way of patching the
kernel though, where we could dynamically tune the code that gets injected.

In order to achive this, let's introduce a new form of dynamic patching,
assiciating a callback to a patching site. This callback gets source and
target locations of the patching request, as well as the number of
instructions to be patched.

Dynamic patching is declared with the new ALTERNATIVE_CB and alternative_cb
directives:
asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
 : "r" (v));
or

alternative_cb callback
mov x0, #0
alternative_cb_end

where callback is the C function computing the alternative.

Reviewed-by: Christoffer Dall 
Reviewed-by: Catalin Marinas 
Signed-off-by: Marc Zyngier 

This is part of XSA-263.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v2:
- Fix typo in the commit message
- Add Stefano's acked-by
---
 xen/arch/arm/alternative.c| 48 +--
 xen/include/asm-arm/alternative.h | 44 +++
 2 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 936cf04956..52ed7edf69 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+/* XXX: Move ARCH_PATCH_INSN_SIZE out of livepatch.h */
+#include 
 #include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
@@ -94,6 +96,23 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 return insn;
 }
 
+static void patch_alternative(const struct alt_instr *alt,
+  const uint32_t *origptr,
+  uint32_t *updptr, int nr_inst)
+{
+const uint32_t *replptr;
+unsigned int i;
+
+replptr = ALT_REPL_PTR(alt);
+for ( i = 0; i < nr_inst; i++ )
+{
+uint32_t insn;
+
+insn = get_alt_insn(alt, origptr + i, replptr + i);
+updptr[i] = cpu_to_le32(insn);
+}
+}
+
 /*
  * The region patched should be read-write to allow __apply_alternatives
  * to replacing the instructions when necessary.
@@ -105,33 +124,38 @@ static int __apply_alternatives(const struct alt_region 
*region,
 paddr_t update_offset)
 {
 const struct alt_instr *alt;
-const u32 *replptr, *origptr;
+const u32 *origptr;
 u32 *updptr;
+alternative_cb_t alt_cb;
 
 printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
 
 for ( alt = region->begin; alt < region->end; alt++ )
 {
-u32 insn;
-int i, nr_inst;
+int nr_inst;
 
-if ( !cpus_have_cap(alt->cpufeature) )
+/* Use ARM_CB_PATCH as an unconditional patch */
+if ( alt->cpufeature < ARM_CB_PATCH &&
+ !cpus_have_cap(alt->cpufeature) )
 continue;
 
-BUG_ON(alt->alt_len != alt->orig_len);
+if ( alt->cpufeature == ARM_CB_PATCH )
+BUG_ON(alt->alt_len != 0);
+else
+BUG_ON(alt->alt_len != alt->orig_len);
 
 origptr = ALT_ORIG_PTR(alt);
 updptr = (void *)origptr + update_offset;
-replptr = ALT_REPL_PTR(alt);
 
-nr_inst = alt->alt_len / sizeof(insn);
+nr_inst = alt->orig_len / ARCH_PATCH_INSN_SIZE;
 
-for ( i = 0; i < nr_inst; i++ )
-{
-insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(updptr + i) = cpu_to_le32(insn);
-}
+if ( alt->cpufeature < ARM_CB_PATCH )
+alt_cb = patch_alternative;
+else
+alt_cb = ALT_REPL_PTR(alt);
+
+alt_cb(alt, origptr, updptr, nr_inst);
 
 /* Ensure the new instructions reached the memory and nuke */
 clean_and_invalidate_dcache_va_range(origptr,
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 4e33d1cdf7..9b4b02811b 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -3,6 +3,8 @@
 
 #include 
 
+#define ARM_CB_PATCH ARM_NCAPS
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -18,16 +20,24 @@ struct alt_instr {
 };
 
 /* Xen: helpers used by common code. */
-#define __ALT_PTR(a,f) ((u32 *)((void *)&(a)->f + (a)->f))
+#define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f)
 #define ALT_ORIG_PTR(a)

[Xen-devel] [PATCH v3 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests

[Julien Grall]

In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
state of the workaround per-vCPU. The field 'pad' in cpu_info is now
repurposed to store flags easily accessible in assembly.

As the hypervisor will always run with the workaround enabled, we may
need to enable (on guest exit) or disable (on guest entry) the
workaround.

A follow-up patch will add fastpath for the workaround for arm64 guests.

Note that check_workaround_ssbd() is used instead of ssbd_get_state()
because the former is implemented using an alternative. Thefore the code
will be shortcut on affected platform.

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v3:
- Add Stefano's reviewed-by

Changes in v2:
- Fix the condition in need_ssbd_flip()
---
 xen/arch/arm/domain.c |  8 
 xen/arch/arm/traps.c  | 20 
 xen/arch/arm/vsmc.c   | 37 +
 xen/include/asm-arm/current.h |  6 +-
 4 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5a2a9a6b83..4baecc2447 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -572,6 +573,13 @@ int vcpu_initialise(struct vcpu *v)
 if ( (rc = vcpu_vtimer_init(v)) != 0 )
 goto fail;
 
+/*
+ * The workaround 2 (i.e SSBD mitigation) is enabled by default if
+ * supported.
+ */
+if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
+
 return rc;
 
 fail:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..315fc61f77 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2011,10 +2011,23 @@ inject_abt:
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
+static inline bool needs_ssbd_flip(struct vcpu *v)
+{
+if ( !check_workaround_ssbd() )
+return false;
+
+return !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
+ cpu_require_ssbd_mitigation();
+}
+
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
 if ( guest_mode(regs) )
 {
+/* If the guest has disabled the workaround, bring it back on. */
+if ( needs_ssbd_flip(current) )
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+
 /*
  * If we pended a virtual abort, preserve it until it gets cleared.
  * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
@@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
  */
 SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
 
+/*
+ * The hypervisor runs with the workaround always present.
+ * If the guest wants it disabled, so be it...
+ */
+if ( needs_ssbd_flip(current) )
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+
 return;
 }
 local_irq_enable();
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 40a80d5760..c4ccae6030 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
 if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
 ret = 0;
 break;
+case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+switch ( get_ssbd_state() )
+{
+case ARM_SSBD_UNKNOWN:
+case ARM_SSBD_FORCE_DISABLE:
+break;
+
+case ARM_SSBD_RUNTIME:
+ret = ARM_SMCCC_SUCCESS;
+break;
+
+case ARM_SSBD_FORCE_ENABLE:
+case ARM_SSBD_MITIGATED:
+ret = ARM_SMCCC_NOT_REQUIRED;
+break;
+}
+break;
 }
 
 set_user_reg(regs, 0, ret);
@@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
 case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
 /* No return value */
 return true;
+
+case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+{
+bool enable = (uint32_t)get_user_reg(regs, 1);
+
+/*
+ * ARM_WORKAROUND_2_FID should only be called when mitigation
+ * state can be changed at runtime.
+ */
+if ( unlikely(get_ssbd_state() != ARM_SSBD_RUNTIME) )
+return true;
+
+if ( enable )
+get_cpu_info()->flags |= CPUINFO_WORKAROUND_2_FLAG;
+else
+get_cpu_info()->flags &= ~CPUINFO_WORKAROUND_2_FLAG;
+
+return true;
+}
 }
 
 return false;
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..f9819b34fc 100644
--- a/xen/include/asm-arm/current.h
+++ 

[Xen-devel] [PATCH v3 03/13] xen/arm: setup: Check errata for boot CPU later on

[Julien Grall]

Some errata will rely on the SMCCC version which is detected by
psci_init().

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/setup.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1d6f6bf37e..ac93de4786 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -171,8 +171,6 @@ static void __init processor_id(void)
 }
 
 processor_setup();
-
-check_local_cpu_errata();
 }
 
 void dt_unreserved_regions(paddr_t s, paddr_t e,
@@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
 nr_cpu_ids = cpus;
 
+/*
+ * Some errata relies on SMCCC version which is detected by psci_init()
+ * (called from smp_init_cpus()).
+ */
+check_local_cpu_errata();
+
 init_xen_time();
 
 gic_init();
-- 
2.11.0


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

[Xen-devel] [PATCH v3 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

[Julien Grall]

As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.

A new capability is also allocated for that purpose, and a config
option.

This is part of XSA-263.

Signed-off-by: Julien Grall 

---
Changes in v3:
- required should be false when then mitigation is not required
on a given CPU

Changes in v2:
- Add the switch in this patch rather than the next one.
- s/supported/required/
---
 xen/arch/arm/Kconfig | 10 +++
 xen/arch/arm/cpuerrata.c | 58 
 xen/include/asm-arm/cpuerrata.h  | 21 +++
 xen/include/asm-arm/cpufeature.h |  3 ++-
 xen/include/asm-arm/smccc.h  |  7 +
 5 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..0e2d027060 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
  Allows a guest to use SBSA Generic UART as a console. The
  SBSA Generic UART implements a subset of ARM PL011 UART.
 
+config ARM_SSBD
+   bool "Speculative Store Bypass Disable" if EXPERT = "y"
+   depends on HAS_ALTERNATIVE
+   default y
+   help
+ This enables mitigation of bypassing of previous stores by speculative
+ loads.
+
+ If unsure, say Y.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..1a6130406c 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -235,6 +235,58 @@ static int enable_ic_inv_hardening(void *data)
 
 #endif
 
+#ifdef CONFIG_ARM_SSBD
+
+/*
+ * Assembly code may use the variable directly, so we need to make sure
+ * it fits in a register.
+ */
+DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
+
+static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+bool required;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+/*
+ * The probe function return value is either negative (unsupported
+ * or mitigated), positive (unaffected), or zero (requires
+ * mitigation). We only need to do anything in the last case.
+ */
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
+
+switch ( (int)res.a0 )
+{
+case ARM_SMCCC_NOT_SUPPORTED:
+return false;
+
+case ARM_SMCCC_NOT_REQUIRED:
+return false;
+
+case ARM_SMCCC_SUCCESS:
+required = true;
+break;
+
+case 1: /* Mitigation not required on this CPU. */
+required = false;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+return false;
+}
+
+if ( required )
+this_cpu(ssbd_callback_required) = 1;
+
+return required;
+}
+#endif
+
 #define MIDR_RANGE(model, min, max) \
 .matches = is_affected_midr_range,  \
 .midr_model = model,\
@@ -336,6 +388,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 .enable = enable_ic_inv_hardening,
 },
 #endif
+#ifdef CONFIG_ARM_SSBD
+{
+.capability = ARM_SSBD,
+.matches = has_ssbd_mitigation,
+},
+#endif
 {},
 };
 
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 4e45b237c8..e628d3ff56 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void)  
   \
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
 
 #undef CHECK_WORKAROUND_HELPER
 
+#ifdef CONFIG_ARM_SSBD
+
+#include 
+
+DECLARE_PER_CPU(register_t, ssbd_callback_required);
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+return this_cpu(ssbd_callback_required);
+}
+
+#else
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+return false;
+}
+
+#endif
+
 #endif /* __ARM_CPUERRATA_H__ */
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index e557a095af..2a5c075d3b 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -43,8 +43,9 @@
 #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
 #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
 #define ARM_HARDEN_BRANCH_PREDICTOR 7
+#define ARM_SSBD 8
 
-#define ARM_NCAPS   8
+#define ARM_NCAPS   9
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 8342cc33fe..a6804cec99 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -258,7 +258,14 @@ struct arm_smccc_res {
   ARM_SMCCC_OWNER_ARCH, \
  

[Xen-devel] [PATCH v3 07/13] xen/arm: Simplify alternative patching of non-writable region

[Julien Grall]

During the MMU setup process, Xen will set SCTLR_EL2.WNX
(Write-Non-eXecutable) bit. Because of that, the alternative code need
to re-mapped the region in a difference place in order to modify the
text section.

At the moment, the function patching the code is only aware of the
re-mapped region. This requires the caller to mess with Xen internal in
order to have function such as is_active_kernel_text() working.

All the interactions with Xen internal can be removed by specifying the
offset between the region patch and the writable region for updating the
instruction

This simplification will also make it easier to integrate dynamic patching
in a follow-up patch. Indeed, the callback address should be in
an original region and not re-mapped only which is writeable non-executable.

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---

Cc: Konrad Rzeszutek Wilk 

Changes in v3:
- Add stefano's reviewed-by

Changes in v2:
- Add commit message
- Remove comment in the code that does not make sense anymore
---
 xen/arch/arm/alternative.c | 42 +-
 1 file changed, 13 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 9ffdc475d6..936cf04956 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 /*
  * The region patched should be read-write to allow __apply_alternatives
  * to replacing the instructions when necessary.
+ *
+ * @update_offset: Offset between the region patched and the writable
+ * region for the update. 0 if the patched region is writable.
  */
-static int __apply_alternatives(const struct alt_region *region)
+static int __apply_alternatives(const struct alt_region *region,
+paddr_t update_offset)
 {
 const struct alt_instr *alt;
-const u32 *replptr;
-u32 *origptr;
+const u32 *replptr, *origptr;
+u32 *updptr;
 
 printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
@@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region 
*region)
 BUG_ON(alt->alt_len != alt->orig_len);
 
 origptr = ALT_ORIG_PTR(alt);
+updptr = (void *)origptr + update_offset;
 replptr = ALT_REPL_PTR(alt);
 
 nr_inst = alt->alt_len / sizeof(insn);
@@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region 
*region)
 for ( i = 0; i < nr_inst; i++ )
 {
 insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(origptr + i) = cpu_to_le32(insn);
+*(updptr + i) = cpu_to_le32(insn);
 }
 
 /* Ensure the new instructions reached the memory and nuke */
@@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
 paddr_t xen_size = _end - _start;
 unsigned int xen_order = get_order_from_bytes(xen_size);
 void *xenmap;
-struct virtual_region patch_region = {
-.list = LIST_HEAD_INIT(patch_region.list),
-};
 
 BUG_ON(patched);
 
@@ -177,31 +179,13 @@ static int __apply_alternatives_multi_stop(void *unused)
 /* Re-mapping Xen is not expected to fail during boot. */
 BUG_ON(!xenmap);
 
-/*
- * If we generate a new branch instruction, the target will be
- * calculated in this re-mapped Xen region. So we have to register
- * this re-mapped Xen region as a virtual region temporarily.
- */
-patch_region.start = xenmap;
-patch_region.end = xenmap + xen_size;
-register_virtual_region(_region);
+region.begin = __alt_instructions;
+region.end = __alt_instructions_end;
 
-/*
- * Find the virtual address of the alternative region in the new
- * mapping.
- * alt_instr contains relative offset, so the function
- * __apply_alternatives will patch in the re-mapped version of
- * Xen.
- */
-region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
-region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
-
-ret = __apply_alternatives();
+ret = __apply_alternatives(, xenmap - (void *)_start);
 /* The patching is not expected to fail during boot. */
 BUG_ON(ret != 0);
 
-unregister_virtual_region(_region);
-
 vunmap(xenmap);
 
 /* Barriers provided by the cache flushing */
@@ -235,7 +219,7 @@ int apply_alternatives(const struct alt_instr *start, const 
struct alt_instr *en
 .end = end,
 };
 
-return __apply_alternatives();
+return __apply_alternatives(, 0);
 }
 
 /*
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH v3 02/13] xen/arm64: entry: Use named label in guest_sync

[Julien Grall]

This will improve readability for future changes.

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/arm64/entry.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index ffa9a1c492..e2344e565f 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -226,11 +226,11 @@ guest_sync:
 mrs x1, esr_el2
 lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
 cmp x1, #HSR_EC_HVC64
-b.ne1f  /* Not a HVC skip fastpath. */
+b.neguest_sync_slowpath /* Not a HVC skip fastpath. */
 
 mrs x1, esr_el2
 and x1, x1, #0x /* Check the immediate [0:16] 
*/
-cbnzx1, 1f  /* should be 0 for HVC #0 */
+cbnzx1, guest_sync_slowpath /* should be 0 for HVC #0 */
 
 /*
  * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
@@ -241,7 +241,7 @@ guest_sync:
  * be encoded as an immediate for cmp.
  */
 eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
-cbnzw0, 1f
+cbnzw0, guest_sync_slowpath
 
 /*
  * Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,7 +250,7 @@ guest_sync:
 mov x1, xzr
 eret
 
-1:
+guest_sync_slowpath:
 /*
  * x0/x1 may have been scratch by the fast path above, so avoid
  * to save them.
-- 
2.11.0


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

[Xen-devel] [PATCH v3 05/13] xen/arm: Add command line option to control SSBD mitigation

[Julien Grall]

On a system where the firmware implements ARCH_WORKAROUND_2, it may be
useful to either permanently enable or disable the workaround for cases
where the user decides that they'd rather not get a trap overhead, and
keep the mitigation permanently on or off instead of switching it on
exception entry/exit. In any case, default to mitigation being enabled.

The new command line option is implemented as list of one option to
follow x86 option and also allow to extend it more easily in the future.

Note that for convenience, the full implemention of the workaround is
done in the .matches callback.

Lastly, a accessor is provided to know the state of the mitigation.

After this patch, there are 3 methods complementing each other to find the
state of the mitigation:
- The capability ARM_SSBD indicates the platform is affected by the
  vulnerability. This will also return false if the user decide to force
  disabled the mitigation (spec-ctrl="ssbd=force-disable"). The
  capability is useful for putting shortcut in place using alternative.
- ssbd_state indicates the global state of the mitigation (e.g
  unknown, force enable...). The global state is required to report
  the state to a guest.
- The per-cpu ssbd_callback_required indicates whether a pCPU
  requires to call the SMC. This allows to shortcut SMC call
  and save an entry/exit to EL3.

This is part of XSA-263.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Fix typo in the name

Changes in v2:
- Move out some code to the previous patch.
- Update the commit message with more background
---
 docs/misc/xen-command-line.markdown | 18 
 xen/arch/arm/cpuerrata.c| 88 ++---
 xen/include/asm-arm/cpuerrata.h | 21 +
 3 files changed, 120 insertions(+), 7 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 8712a833a2..962028b6ed 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 
670ms. Any number
 is being interpreted as a custom timeout in milliseconds. Zero or boolean
 false disable the quirk workaround, which is also the default.
 
+### spec-ctrl (Arm)
+> `= List of [ ssbd=force-disable|runtime|force-enable ]`
+
+Controls for speculative execution sidechannel mitigations.
+
+The option `ssbd=` is used to control the state of Speculative Store
+Bypass Disable (SSBD) mitigation.
+
+* `ssbd=force-disable` will keep the mitigation permanently off. The guest
+will not be able to control the state of the mitigation.
+* `ssbd=runtime` will always turn on the mitigation when running in the
+hypervisor context. The guest will be to turn on/off the mitigation for
+itself by using the firmware interface ARCH\_WORKAROUND\_2.
+* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
+not be able to control the state of the mitigation.
+
+By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
+
 ### spec-ctrl (x86)
 > `= List of [ , xen=, {pv,hvm,msr-sc,rsb}=,
 >  bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}= ]`
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1a6130406c..4292008692 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
 
 #ifdef CONFIG_ARM_SSBD
 
+enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
+
+static int __init parse_spec_ctrl(const char *s)
+{
+const char *ss;
+int rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( !strncmp(s, "ssbd=", 5) )
+{
+s += 5;
+
+if ( !strncmp(s, "force-disable", ss - s) )
+ssbd_state = ARM_SSBD_FORCE_DISABLE;
+else if ( !strncmp(s, "runtime", ss - s) )
+ssbd_state = ARM_SSBD_RUNTIME;
+else if ( !strncmp(s, "force-enable", ss - s) )
+ssbd_state = ARM_SSBD_FORCE_ENABLE;
+else
+rc = -EINVAL;
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("spec-ctrl", parse_spec_ctrl);
+
 /*
  * Assembly code may use the variable directly, so we need to make sure
  * it fits in a register.
@@ -251,20 +286,17 @@ static bool has_ssbd_mitigation(const struct 
arm_cpu_capabilities *entry)
 if ( smccc_ver < SMCCC_VERSION(1, 1) )
 return false;
 
-/*
- * The probe function return value is either negative (unsupported
- * or mitigated), positive (unaffected), or zero (requires
- * mitigation). We only need to do anything in the last case.
- */
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
 
 switch ( 

[Xen-devel] [PATCH v3 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID

[Julien Grall]

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's acked-by
---
 xen/include/asm-arm/smccc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index a6804cec99..74c13f8419 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -254,9 +254,9 @@ struct arm_smccc_res {
 
 #define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
 ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
-  ARM_SMCCC_CONV_32,\
-  ARM_SMCCC_OWNER_ARCH, \
-  0x8000)
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x8000)
 
 #define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
 ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 05/11] ResourceCondition: Break out PropCompareBase

[Ian Jackson]

Make a base class so we can easily invent other kinds of resource
property condition.  The child is responsible only for stringification
and the actual comparison.

These classes does not need Exporter, so drop all that.  Use `use
parent' to import the base class.

Signed-off-by: Ian Jackson 
---
 Osstest/ResourceCondition/PropCompareBase.pm | 66 
 Osstest/ResourceCondition/PropMinVer.pm  | 45 +++
 2 files changed, 73 insertions(+), 38 deletions(-)
 create mode 100644 Osstest/ResourceCondition/PropCompareBase.pm

diff --git a/Osstest/ResourceCondition/PropCompareBase.pm 
b/Osstest/ResourceCondition/PropCompareBase.pm
new file mode 100644
index 000..5306bb8
--- /dev/null
+++ b/Osstest/ResourceCondition/PropCompareBase.pm
@@ -0,0 +1,66 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+package Osstest::ResourceCondition::PropCompareBase;
+
+use strict;
+use warnings;
+
+use Osstest;
+use Osstest::TestSupport;
+
+BEGIN {
+use Exporter ();
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+$VERSION = 1.00;
+@ISA = qw(Exporter);
+@EXPORT  = qw();
+%EXPORT_TAGS = ( );
+
+@EXPORT_OK   = qw();
+}
+
+sub new {
+my ($class, $name, $prop, $val) = @_;
+
+die "propname: $prop?" unless propname_check($prop);
+
+return bless {
+   Prop => $prop,
+   Val => $val
+}, $class;
+}
+
+sub check {
+my ($pc, $restype, $resname) = @_;
+
+# Using _cached avoids needing to worry about $dbh_tests being
+# closed/reopened between invocations
+my $hpropq = $dbh_tests->prepare_cached({Prop});
+
+my $row= $hpropq->fetchrow_arrayref();
+$hpropq->finish();
+
+my $propval = $row->[0];
+
+return $pc->_check($propval);
+}
+
+1;
diff --git a/Osstest/ResourceCondition/PropMinVer.pm 
b/Osstest/ResourceCondition/PropMinVer.pm
index 155aefb..1880d7c 100644
--- a/Osstest/ResourceCondition/PropMinVer.pm
+++ b/Osstest/ResourceCondition/PropMinVer.pm
@@ -19,6 +19,8 @@ package Osstest::ResourceCondition::PropMinVer;
 use strict;
 use warnings;
 
+use parent 'Osstest::ResourceCondition::PropCompareBase';
+
 use Osstest;
 use Osstest::TestSupport;
 
@@ -26,52 +28,19 @@ use Sort::Versions;
 
 use overload '""' => 'stringify';
 
-BEGIN {
-use Exporter ();
-our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
-$VERSION = 1.00;
-@ISA = qw(Exporter);
-@EXPORT  = qw();
-%EXPORT_TAGS = ( );
-
-@EXPORT_OK   = qw();
-}
-
-sub new {
-my ($class, $name, $prop, $val) = @_;
-
-die "propname: $prop?" unless propname_check($prop);
-
-return bless {
-   Prop => $prop,
-   MinVal => $val
-}, $class;
-}
-
 sub stringify {
 my ($pmv) = @_;
-return "$pmv->{MinVal} >=(v) property $pmv->{Prop}";
+return "$pmv->{Val} >=(v) property $pmv->{Prop}";
 }
 
-sub check {
-my ($pmv, $restype, $resname) = @_;
-
-# Using _cached avoids needing to worry about $dbh_tests being
-# closed/reopened between invocations
-my $hpropq = $dbh_tests->prepare_cached({Prop});
-
-my $row= $hpropq->fetchrow_arrayref();
-$hpropq->finish();
+sub _check {
+my ($pmv, $propval) = @_;
 
-return 1 unless $row; # No prop == no restriction.
+return 1 unless defined $propval; # No prop == no restriction.
 
 # If the maximum minimum is >= to the resource's minimum then the
 # resource meets the requirement.
-return versioncmp($pmv->{MinVal}, $row->[0]) >= 0;
+return versioncmp($pmv->{Val}, $propval) >= 0;
 }
 
 1;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 06/11] ResourceCondition: Provide PropEq

[Ian Jackson]

This can be used, for example, with the following entry in a hostflags
runvar:
   PropEq:Firmware:uefi

Signed-off-by: Ian Jackson 
---
 Osstest/ResourceCondition/PropEq.pm | 38 +
 1 file changed, 38 insertions(+)
 create mode 100644 Osstest/ResourceCondition/PropEq.pm

diff --git a/Osstest/ResourceCondition/PropEq.pm 
b/Osstest/ResourceCondition/PropEq.pm
new file mode 100644
index 000..cf70994
--- /dev/null
+++ b/Osstest/ResourceCondition/PropEq.pm
@@ -0,0 +1,38 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+package Osstest::ResourceCondition::PropEq;
+
+use strict;
+use warnings;
+
+use parent 'Osstest::ResourceCondition::PropCompareBase';
+
+use Osstest;
+use Osstest::TestSupport;
+
+sub stringify {
+my ($pe) = @_;
+return "'$pe->{Val}' eq property $pe->{Prop}";
+}
+
+sub _check {
+my ($pe, $propval) = @_;
+$propval //= '';
+return $pe->{Val} eq $propval;
+}
+
+1;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 10/11] TestSupport: substeps: work if steps in ad-hoc tests take >1s

[Ian Jackson]

When running by hand, OSSTEST_TESTID is not set.  We provide a value
with the time and the pid in it, so that rerunning the script by hand
works, even though in production this would result in multiple
identically-named substeps.

But we need to fix this value for the duration of the script.
Otherwise when it calls substep_finish, if the time has moved on, it
computes a different OSSTEST_TESTID and therefore a different substep
name, and then the substep machinery smells a rat and bombs out.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6de566c..7bc40f3 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -245,7 +245,7 @@ END
 sub complete_testid ($) {
 my ($testidr) = @_;
 $$testidr =~ s{^(?=/)}{
-   $ENV{OSSTEST_TESTID} // sprintf('SUBSTEP-%s-%s', time, $$)
+   $ENV{OSSTEST_TESTID} //= sprintf('SUBSTEP-%s-%s', time, $$)
 }e;
 }
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 01/11] ts-xen-install: Drop obsolete --check and $checkmode

[Ian Jackson]

Since 5edec3222ff14b8200d5b41ed9af3c8d04c27314
  ts-xen-build-check: reimplementation ...
in 2011 we have a fully general version, and the --check option
is no longer used.

And since 467d6239daa352483ec8fef003bd4fc723702b77
  pygrub: guest kernel install: move target_extract_jobdist_path into Osstest
also in 2011, --check has not worked properly, because that
commit moved the relevant code somewhere where $checkmode was
not available and simply dropped the check.

So remove the vestigial code in ts-xen-build.  As for @ARGV, we simply
die if we see something that looks like an option.

Signed-off-by: Ian Jackson 
---
 ts-xen-install | 46 ++
 1 file changed, 18 insertions(+), 28 deletions(-)

diff --git a/ts-xen-install b/ts-xen-install
index a9f8631..fcbb697 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -26,23 +26,17 @@ use Osstest::TestSupport;
 use Data::Dumper;
 use Osstest::CXFabric;
 
-my $checkmode= 0;
-
 tsreadconfig();
 
 our @hos;
 
-if (@ARGV and $ARGV[0] eq '--check') {
-$checkmode= 1;
-shift @ARGV;
-logm("checking builds are done...");
-} else {
-if (!@ARGV) {
-   push @ARGV, 'host';
-}
-foreach my $k (@ARGV) {
-push @hos, selecthost($k);
-}
+die if @ARGV && $ARGV[0] =~ m/^-/;
+
+if (!@ARGV) {
+push @ARGV, 'host';
+}
+foreach my $k (@ARGV) {
+push @hos, selecthost($k);
 }
 
 our $ho;
@@ -372,19 +366,15 @@ sub forbidden () {
 END
 }
 
-if ($checkmode) {
-extract();
-} else {
-die if @hos > 1;
-$ho= $hos[0];
+die if @hos > 1;
+$ho= $hos[0];
 
-packages();
-extradebs();
-extract();
-forbidden();
-adjustconfig();
-setupboot();
-setupinitd();
-ensurebridge();
-hosts();
-}
+packages();
+extradebs();
+extract();
+forbidden();
+adjustconfig();
+setupboot();
+setupinitd();
+ensurebridge();
+hosts();
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 00/11] dmrestrict audit: Preparatory fixes

[Ian Jackson]

From: Ian Jackson 

While working on auditing dm restriction, I came up with these
miscellaneous improvements, bugfixes, slightly refactorings, and minor
new features.  I intend to push them to osstest pretest soon to get
them out of my queue.

Ian Jackson (11):
  ts-xen-install: Drop obsolete --check and $checkmode
  cs-adjust-flight: Allow adjusting play flights after start
  sg-run-job: Allow suppression of consequences of per-host-ts fail
  TestSupport: Break out target_extract_distpart
  ResourceCondition: Break out PropCompareBase
  ResourceCondition: Provide PropEq
  config: ExtraDebs: replace with DebianExtraPackages
  ts-xen-install: DebianExtraPackages: call apt-get -f install
  sg-run-job: add some comments about guest state
  TestSupport: substeps: work if steps in ad-hoc tests take >1s
  TestSupport: guest_var_boolean: Understand `y' and `1' as well

 Osstest/ResourceCondition/PropCompareBase.pm | 66 +++
 Osstest/ResourceCondition/PropEq.pm  | 38 +++
 Osstest/ResourceCondition/PropMinVer.pm  | 45 ++---
 Osstest/TestSupport.pm   | 14 +++-
 README   |  9 +++
 cs-adjust-flight |  6 +-
 production-config|  8 +--
 sg-run-job   | 15 -
 ts-xen-install   | 97 +---
 9 files changed, 212 insertions(+), 86 deletions(-)
 create mode 100644 Osstest/ResourceCondition/PropCompareBase.pm
 create mode 100644 Osstest/ResourceCondition/PropEq.pm

-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 04/11] TestSupport: Break out target_extract_distpart

[Ian Jackson]

No functional change.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 10 +-
 ts-xen-install |  4 +---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index cebeb0d..6de566c 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -70,7 +70,8 @@ BEGIN {
   target_run_apt
   target_install_packages target_install_packages_norec
   target_jobdir target_extract_jobdistpath_subdir
-  target_extract_jobdistpath target_tftp_prefix
+  target_extract_jobdistpath target_extract_distpart
+ target_tftp_prefix
   lv_create lv_dev_mapper
 
   poll_loop tcpconnect await_tcp
@@ -2343,6 +2344,13 @@ sub target_extract_jobdistpath ($) {
 target_cmd_root($ho, "cd / && tar -hzxf $distcopy", 300);
 }
 
+sub target_extract_distpart ($$;$) {
+my ($ho, $part, $distpath_r) = @_;
+target_extract_jobdistpath($ho, $part, "path_${part}dist",
+   $r{"$ho->{Ident}_${part}buildjob"} // $r{"${part}buildjob"},
+   $distpath_r);
+}
+
 sub target_tftp_prefix ($) {
 my ($ho) = @_;
 
diff --git a/ts-xen-install b/ts-xen-install
index fcbb697..17f7662 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -81,9 +81,7 @@ sub extract () {
 push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
 
 foreach my $part (@parts) {
-target_extract_jobdistpath($ho, $part, "path_${part}dist",
-   $r{"$ho->{Ident}_${part}buildjob"} // $r{"${part}buildjob"},
-   \%distpath);
+   target_extract_distpart($ho, $part, \%distpath);
 }
 if (target_file_exists($ho, "/usr/lib64/efi/xen.efi")) {
target_cmd_root($ho,

[Xen-devel] [OSSTEST PATCH 09/11] sg-run-job: add some comments about guest state

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 sg-run-job | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index e1dc2d2..0a3f688 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -604,11 +604,13 @@ proc test-guest-migr {g} {
 }
 
 proc test-guest {g} {
+# guest is expected to be running, and ends up stopped
 test-guest-migr $g
 test-guest-nomigr $g
 }
 
 proc test-guest-nomigr {g} {
+# guest is expected to be running and ends up stopped
 run-ts . =   ts-guest-stop+ host $g
 
 repeat-ts 10 =.repeat \
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 07/11] config: ExtraDebs: replace with DebianExtraPackages

[Ian Jackson]

`ExtraDebs' is a silly name.  Also the semantics are rather
inflexible; we might want to install specific packages rather than
the contents of a whole directory.

And, document it.

This variable has only just been introduced, so hopefully it is OK to
replace and rename it now without causing too much disruption.

(osstest's own production runs each use their own copy of the config,
so they will be fine.  It's just downstreams, or users whose config is
set up to use one not in their own tree, who will be affected.)

Signed-off-by: Ian Jackson 

--

Signed-off-by: Ian Jackson 
---
 README|  9 +
 production-config |  8 
 ts-xen-install| 46 --
 3 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/README b/README
index 7b7bc52..2dfd4de 100644
--- a/README
+++ b/README
@@ -537,6 +537,15 @@ DebianNonfreeFirmware
   grep-dctrl (for example because it's not Debian) then you must set
   this to the empty string, by writing  DebianNonfreeFirmware=''
 
+DebianExtraPackages___ [... ]
+  Extra packages, or directories of them, to install on every Debian
+  host (dom0).  Each variable is a space-separated list of items.
+  Each  is relative to Images unless it starts with `/' or `./'.
+  It should be one of the following:
+/update packages, dpkg -iGROEB
+[.../]__.deb  install package, dpkg -iB
+[.../]__.deb   install _.deb
+
 Tftp*
Settings related to the tftp server:
 
diff --git a/production-config b/production-config
index aa414d0..d89e89a 100644
--- a/production-config
+++ b/production-config
@@ -106,10 +106,10 @@ MicrocodeUpdateI386 microcode.x86.2015-06-12.cpio
 # Update with ./mg-netgrub-loader-update
 TftpGrubVersion -XX-XX
 
-ExtraDebs_uefi_i386_jessie   2018-04-01
-ExtraDebs_uefi_amd64_jessie  2018-04-01
-ExtraDebs_uefi_i386_stretch  2018-04-01
-ExtraDebs_uefi_amd64_stretch 2018-04-01
+DebianExtraPackages_uefi_i386_jessie   extradebs-uefi-i386-2018-04-01/
+DebianExtraPackages_uefi_amd64_jessie  extradebs-uefi-amd64-2018-04-01/
+DebianExtraPackages_uefi_i386_stretch  extradebs-uefi-i386-2018-04-01/
+DebianExtraPackages_uefi_amd64_stretch extradebs-uefi-amd64-2018-04-01/
 
 XenUsePath /usr/groups/xencore/systems/bin/xenuse
 XenUseUser osstest
diff --git a/ts-xen-install b/ts-xen-install
index 17f7662..d3a9d11 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -20,6 +20,7 @@ use DBI;
 BEGIN { unshift @INC, qw(.); }
 use Osstest;
 use File::Path;
+use File::Basename;
 use POSIX;
 use Osstest::Debian;
 use Osstest::TestSupport;
@@ -66,14 +67,47 @@ sub packages () {
 if toolstack($ho)->{ExtraPackages};
 }
 
+sub some_extradebs ($) {
+my ($items) = @_;
+my $cfgvar = join('_', @$items);
+my $specs = $c{$cfgvar};
+if (!length $specs) {
+   logm("$cfgvar: no extra debs");
+   return;
+}
+my $counter = 0;
+my $rsync_installed;
+foreach my $spec (split /\s+/, $specs) {
+   my $path = $spec;
+   $path = "$c{Images}/$path" unless $path =~ m{^/|^\./};
+   my ($ontarget, $dpkgopts);
+   if ($path =~ m{/$}) {
+   $ontarget = "extrapackages-$cfgvar-$counter"; $counter++;
+   $dpkgopts = '-iGROEB';
+   logm("$cfgvar: updating packages from directory $path");
+   target_install_packages($ho, 'rsync') unless $rsync_installed++;
+   target_putfile_root($ho,300, "$path/.", $ontarget, '-r');
+   } elsif ($path =~ m{\.deb$}) {
+   $path =~ s{_\.deb}{ "_$r{arch}.deb" }e;
+   logm("$cfgvar: installing $path");
+   $ontarget = basename($path);
+   $dpkgopts = '-iB';
+   target_putfile_root($ho,300, $path, $ontarget);
+   } else {
+   die "no / or . deb in $spec ?";
+   }
+   target_cmd_root($ho,
+   "dpkg --force-confold $dpkgopts $ontarget {Suite};
+
+# $c{ DebianExtraPackages___ }
 my $firmware = get_host_property($ho, "firmware", "bios");
-my $version = $c{ "ExtraDebs_${firmware}_$r{arch}_$ho->{Suite}" };
-return unless $version;
-target_install_packages($ho, 'rsync');
-my $extradebs = "$c{Images}/extradebs-$firmware-$r{arch}-$version";
-target_putfile_root($ho,300, "$extradebs/.", 'extradebs', '-r');
-target_cmd_root($ho,"dpkg --force-confold -iGROEB extradebs 
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [OSSTEST PATCH 11/11] TestSupport: guest_var_boolean: Understand `y' and `1' as well

[Ian Jackson]

Previously this would treat `y' and `1' as false, which is very
confusing.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 7bc40f3..d8ed02d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1825,7 +1825,7 @@ sub guest_var ($$$) {
 
 sub guest_var_boolean ($$) {
 my ($gho, $runvartail) = @_;
-return guest_var($gho, $runvartail, 'false') =~ m/true/;
+return guest_var($gho, $runvartail, 'false') =~ m/true|y|1/;
 }
 
 sub guest_var_commalist ($$) {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 03/11] sg-run-job: Allow suppression of consequences of per-host-ts fail

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 sg-run-job | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index aa97ee6..e1dc2d2 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -216,7 +216,8 @@ proc testid_matches_globs {testid globs} {
 #   where STATUS is the job/step status to be used if the step
 #   status is not as expected, and the special meanings are:
 #
-#   -  Only for run-ts; suprresses exception on failure.
+#   -  for run-ts; suprresses exception on failure.
+#  for per-host-ts; suppresses consequences of failure.
 #   !  Run this even if the job is being truncated.
 #  (for per-host-ts, even if the job is no longer $ok)
 #   .  Shorthand for "fail"
@@ -286,6 +287,10 @@ proc iffail-check {iffail okexpr iffail_status_var} {
 global ok
 upvar 1 $iffail_status_var iffail_status
 
+if {[regexp {^-} $iffail]} {
+   # move - to the end, since docs say it should have come first
+   regsub {^-} "$iffail-" {} iffail
+}
 if {[regexp {^!?\.$} $iffail]} {
 regsub {\.$} $iffail fail iffail
 }
@@ -444,8 +449,10 @@ proc per-host-ts {iffail ident script args} {
 foreach host $need_xen_hosts await $awaitl {
 if {![reap-ts $await]} {
 jobdb::logputs stderr "$flight.$jobinfo(job) @$host $args failed"
-set failed 1
-set ok 0
+   if {[string compare - $iffail_status]} {
+   set failed 1
+   set ok 0
+   }
 }
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/altp2m: set access_required properly for all altp2ms

[Jan Beulich]

>>> On 11.06.18 at 17:12,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Not the least to avoid this I think ...

> @@ -719,6 +720,22 @@ int arch_domain_soft_reset(struct domain *d)
>  return ret;
>  }
>  
> +void arch_domain_set_access_required(struct domain *d, bool access_required)

... this belongs somewhere in x86/mm/.

> +{
> +unsigned int i;
> +
> +if ( !altp2m_active(d) )
> + return;

Hard tab.

> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +{
> +if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
> +continue;

Yet another EPT-specific check outside of EPT code. Why can't you
check the pointer you use ...

> +d->arch.altp2m_p2m[i]->access_required = access_required;

... here against NULL, and otherwise do the store irrespective
of the value of d->arch.altp2m_eptp[i]?

> @@ -210,7 +211,7 @@ static int p2m_init_altp2m(struct domain *d)
>  return -ENOMEM;
>  }
>  p2m->p2m_class = p2m_alternate;
> -p2m->access_required = 1;
> +p2m->access_required = hostp2m->access_required;

There must have been a reason to have it start out as 1. You
mention the fact in the description, but not why it is okay (or
even necessary) to change it.

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1094,6 +1094,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  domain_pause(d);
>  p2m_get_hostp2m(d)->access_required =
>  op->u.access_required.access_required;
> +arch_domain_set_access_required(d,
> +op->u.access_required.access_required);

Perhaps the setting of the host p2m field should move into that
function as well?

Jan



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

[Xen-devel] [PATCH v2] xen/netfront: raise max number of slots in xennet_get_responses()

[Juergen Gross]

The max number of slots used in xennet_get_responses() is set to
MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD).

In old kernel-xen MAX_SKB_FRAGS was 18, while nowadays it is 17. This
difference is resulting in frequent messages "too many slots" and a
reduced network throughput for some workloads (factor 10 below that of
a kernel-xen based guest).

Replacing MAX_SKB_FRAGS by XEN_NETIF_NR_SLOTS_MIN for calculation of
the max number of slots to use solves that problem (tests showed no
more messages "too many slots" and throughput was as high as with the
kernel-xen based guest system).

Replace MAX_SKB_FRAGS-2 by XEN_NETIF_NR_SLOTS_MIN-1 in
netfront_tx_slot_available() for making it clearer what is really being
tested without actually modifying the tested value.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
---
 drivers/net/xen-netfront.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 679da1abd73c..922ce0abf5cf 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -239,7 +239,7 @@ static void rx_refill_timeout(struct timer_list *t)
 static int netfront_tx_slot_available(struct netfront_queue *queue)
 {
return (queue->tx.req_prod_pvt - queue->tx.rsp_cons) <
-   (NET_TX_RING_SIZE - MAX_SKB_FRAGS - 2);
+   (NET_TX_RING_SIZE - XEN_NETIF_NR_SLOTS_MIN - 1);
 }
 
 static void xennet_maybe_wake_tx(struct netfront_queue *queue)
@@ -790,7 +790,7 @@ static int xennet_get_responses(struct netfront_queue 
*queue,
RING_IDX cons = queue->rx.rsp_cons;
struct sk_buff *skb = xennet_get_rx_skb(queue, cons);
grant_ref_t ref = xennet_get_rx_ref(queue, cons);
-   int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD);
+   int max = XEN_NETIF_NR_SLOTS_MIN + (rx->status <= RX_COPY_THRESHOLD);
int slots = 1;
int err = 0;
unsigned long ret;
-- 
2.13.7


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

[Xen-devel] [PATCH v5 2/3] Input: xen-kbdfront - fix multi-touch XenStore node's locations

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

kbdif protocol describes multi-touch device parameters as a
part of frontend's XenBus configuration nodes while they
belong to backend's configuration. Fix this by reading the
parameters as defined by the protocol.

Fixes: 49aac8204da5 ("Input: xen-kbdfront - add multi-touch support")

Signed-off-by: Oleksandr Andrushchenko 
---
 drivers/input/misc/xen-kbdfront.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index d91f3b1c5375..92d739649022 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -229,7 +229,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
}
}
 
-   touch = xenbus_read_unsigned(dev->nodename,
+   touch = xenbus_read_unsigned(dev->otherend,
 XENKBD_FIELD_FEAT_MTOUCH, 0);
if (touch) {
ret = xenbus_write(XBT_NIL, dev->nodename,
@@ -304,13 +304,13 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!mtouch)
goto error_nomem;
 
-   num_cont = xenbus_read_unsigned(info->xbdev->nodename,
+   num_cont = xenbus_read_unsigned(info->xbdev->otherend,
XENKBD_FIELD_MT_NUM_CONTACTS,
1);
-   width = xenbus_read_unsigned(info->xbdev->nodename,
+   width = xenbus_read_unsigned(info->xbdev->otherend,
 XENKBD_FIELD_MT_WIDTH,
 XENFB_WIDTH);
-   height = xenbus_read_unsigned(info->xbdev->nodename,
+   height = xenbus_read_unsigned(info->xbdev->otherend,
  XENKBD_FIELD_MT_HEIGHT,
  XENFB_HEIGHT);
 
-- 
2.17.1


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

[Xen-devel] [PATCH v5 3/3] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed to Android then the latter won't
automatically show on-screen keyboard as it expects that a
physical keyboard device can be used for typing.

Utilize keyboard and pointer device XenStore feature fields to
configure which virtual devices are created:
 - set "feature-disable-keyboard" to 1 if no keyboard device
   needs to be created
 - set "feature-disable-pointer" to 1 if no pointer device
   needs to be created
Keep old behavior by default.

Signed-off-by: Oleksandr Andrushchenko 
Suggested-by: Andrii Chepurnyi 
Tested-by: Andrii Chepurnyi 
---
 drivers/input/misc/xen-kbdfront.c | 177 ++
 1 file changed, 106 insertions(+), 71 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 92d739649022..f50fba1962ec 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -63,6 +63,9 @@ static void xenkbd_disconnect_backend(struct xenkbd_info *);
 static void xenkbd_handle_motion_event(struct xenkbd_info *info,
   struct xenkbd_motion *motion)
 {
+   if (unlikely(!info->ptr))
+   return;
+
input_report_rel(info->ptr, REL_X, motion->rel_x);
input_report_rel(info->ptr, REL_Y, motion->rel_y);
if (motion->rel_z)
@@ -73,6 +76,9 @@ static void xenkbd_handle_motion_event(struct xenkbd_info 
*info,
 static void xenkbd_handle_position_event(struct xenkbd_info *info,
 struct xenkbd_position *pos)
 {
+   if (unlikely(!info->ptr))
+   return;
+
input_report_abs(info->ptr, ABS_X, pos->abs_x);
input_report_abs(info->ptr, ABS_Y, pos->abs_y);
if (pos->rel_z)
@@ -97,6 +103,9 @@ static void xenkbd_handle_key_event(struct xenkbd_info *info,
return;
}
 
+   if (unlikely(!dev))
+   return;
+
input_event(dev, EV_KEY, key->keycode, value);
input_sync(dev);
 }
@@ -192,7 +201,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
int ret, i;
-   unsigned int abs, touch;
+   bool with_mtouch, with_kbd, with_ptr;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
 
@@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
 
-   /* Set input abs params to match backend screen res */
-   abs = xenbus_read_unsigned(dev->otherend,
-  XENKBD_FIELD_FEAT_ABS_POINTER, 0);
-   ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_WIDTH,
- ptr_size[KPARAM_X]);
-   ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_HEIGHT,
- ptr_size[KPARAM_Y]);
-   if (abs) {
-   ret = xenbus_write(XBT_NIL, dev->nodename,
-  XENKBD_FIELD_REQ_ABS_POINTER, "1");
-   if (ret) {
-   pr_warn("xenkbd: can't request abs-pointer\n");
-   abs = 0;
-   }
-   }
+   /*
+* The below are reverse logic, e.g. if the feature is set, then
+* do not expose the corresponding virtual device.
+*/
+   with_kbd = !xenbus_read_unsigned(dev->otherend,
+XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
+
+   with_ptr = !xenbus_read_unsigned(dev->otherend,
+XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
 
-   touch = xenbus_read_unsigned(dev->otherend,
-XENKBD_FIELD_FEAT_MTOUCH, 0);
-   if (touch) {
+   /* Direct logic: if set, then create multi-touch device. */
+   with_mtouch = xenbus_read_unsigned(dev->otherend,
+  XENKBD_FIELD_FEAT_MTOUCH, 0);
+   if (with_mtouch) {
ret = xenbus_write(XBT_NIL, dev->nodename,
   XENKBD_FIELD_REQ_MTOUCH, "1");
if (ret) {
pr_warn("xenkbd: can't request multi-touch");
-   touch = 0;
+   with_mtouch = 0;
}
}
 
/* keyboard */
-   kbd = input_allocate_device();
-   if (!kbd)
-   goto error_nomem;
-   kbd->name = "Xen Virtual Keyboard";
-   kbd->phys = info->phys;
-   kbd->id.bustype = BUS_PCI;
-   

[Xen-devel] [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

This is the sync up with the canonical definitions of the input,
sound and display protocols in Xen.

Changes to kbdif:
1. Add missing string constants for {feature|request}-raw-pointer
   to align with the rest of the interface file.

2. Add new XenStore feature fields, so it is possible to individually
   control set of exposed virtual devices for each guest OS:
 - set feature-disable-keyboard to 1 if no keyboard device needs
   to be created
 - set feature-disable-pointer to 1 if no pointer device needs
   to be created

3. Move multi-touch device parameters to backend nodes: these are
described as a part of frontend's XenBus configuration nodes
while they belong to backend's configuration. Fix this by moving
the parameters to the proper section.

Unique-id field:
1. Add unique-id XenBus entry for virtual input and display.

2. Change type of unique-id field to string for sndif to align with
display and input protocols.

Signed-off-by: Oleksandr Andrushchenko 
Cc: Konrad Rzeszutek Wilk 
---
 include/xen/interface/io/displif.h |  8 +++
 include/xen/interface/io/kbdif.h   | 78 ++
 include/xen/interface/io/sndif.h   | 10 ++--
 3 files changed, 71 insertions(+), 25 deletions(-)

diff --git a/include/xen/interface/io/displif.h 
b/include/xen/interface/io/displif.h
index 596578d9be3e..fdc279dc4a88 100644
--- a/include/xen/interface/io/displif.h
+++ b/include/xen/interface/io/displif.h
@@ -189,6 +189,13 @@
  *
  *- Connector settings 
  *
+ * unique-id
+ *  Values: 
+ *
+ *  After device instance initialization each connector is assigned a
+ *  unique ID, so it can be identified by the backend by this ID.
+ *  This can be UUID or such.
+ *
  * resolution
  *  Values: x
  *
@@ -368,6 +375,7 @@
 #define XENDISPL_FIELD_EVT_CHANNEL "evt-event-channel"
 #define XENDISPL_FIELD_RESOLUTION  "resolution"
 #define XENDISPL_FIELD_BE_ALLOC"be-alloc"
+#define XENDISPL_FIELD_UNIQUE_ID   "unique-id"
 
 /*
  **
diff --git a/include/xen/interface/io/kbdif.h b/include/xen/interface/io/kbdif.h
index 2a9510ade701..b4439cf48220 100644
--- a/include/xen/interface/io/kbdif.h
+++ b/include/xen/interface/io/kbdif.h
@@ -51,6 +51,18 @@
  * corresponding entries in XenStore and puts 1 as the value of the entry.
  * If a feature is not supported then 0 must be set or feature entry omitted.
  *
+ * feature-disable-keyboard
+ *  Values: 
+ *
+ *  If there is no need to expose a virtual keyboard device by the
+ *  frontend then this must be set to 1.
+ *
+ * feature-disable-pointer
+ *  Values: 
+ *
+ *  If there is no need to expose a virtual pointer device by the
+ *  frontend then this must be set to 1.
+ *
  * feature-abs-pointer
  *  Values: 
  *
@@ -63,6 +75,22 @@
  *  Backends, which support reporting of multi-touch events
  *  should set this to 1.
  *
+ * feature-raw-pointer
+ *  Values:
+ *
+ *  Backends, which support reporting raw (unscaled) absolute coordinates
+ *  for pointer devices should set this to 1. Raw (unscaled) values have
+ *  a range of [0, 0x7fff].
+ *
+ *---  Device Instance Parameters 
+ *
+ * unique-id
+ *  Values: 
+ *
+ *  After device instance initialization it is assigned a unique ID,
+ *  so every instance of the frontend can be identified by the backend
+ *  by this ID. This can be UUID or such.
+ *
  *- Pointer Device Parameters 
  *
  * width
@@ -77,6 +105,25 @@
  *  Maximum Y coordinate (height) to be used by the frontend
  *  while reporting input events, pixels, [0; UINT32_MAX].
  *
+ *--- Multi-touch Device Parameters --
+ *
+ * multi-touch-num-contacts
+ *  Values: 
+ *
+ *  Number of simultaneous touches reported.
+ *
+ * multi-touch-width
+ *  Values: 
+ *
+ *  Width of the touch area to be used by the frontend
+ *  while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ * multi-touch-height
+ *  Values: 
+ *
+ *  Height of the touch area to be used by the frontend
+ *  while reporting input events, pixels, [0; UINT32_MAX].
+ *
  *
  *Frontend XenBus Nodes
  *
@@ -98,6 +145,13 @@
  *
  *  Request backend to report multi-touch events.
  *
+ * request-raw-pointer
+ *  Values: 
+ *
+ *  Request backend to report raw unscaled absolute pointer coordinates.
+ *  This option is only valid if request-abs-pointer is also 

[Xen-devel] [PATCH v5 0/3] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Hi, all!

This patch series synchronizes Xen canonical protocol definitions
which allow the last two patches in the series to update Xen
kbdfront driver with a fix and v5 of the patch to allow better
run-time configuration for xen-kbdfront.

As xen-kbdfront patches rely on protocol changes from patch 1 I am
sending these all together: Boris, Juergen, if you and Dmitry do not
mind, can we have patch 1 applied through Dmitry's tree?

Thank you,
Oleksandr

Changes since v4:
- Added required changes to Xen protocols
- Added a fix for multi-touch XenStore node's locations
- No changes to "Input: xen-kbdfront - allow better run-time
  configuration"

Changes since v3:
- do not connect backend if all virtual devices are disabled (Dmitry)

Changes since v2:
- based on XenStore kbdif features to control which devices are
  exposed instead of module parameters.

Oleksandr Andrushchenko (3):
  xen: Sync up with the canonical protocol definitions in Xen
  Input: xen-kbdfront - fix multi-touch XenStore node's locations
  Input: xen-kbdfront - allow better run-time configuration

 drivers/input/misc/xen-kbdfront.c  | 183 +
 include/xen/interface/io/displif.h |   8 ++
 include/xen/interface/io/kbdif.h   |  78 +---
 include/xen/interface/io/sndif.h   |  10 +-
 4 files changed, 180 insertions(+), 99 deletions(-)

-- 
2.17.1


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

Re: [Xen-devel] [PATCH v2 9/9] x86/vmx: Don't leak EFER.NXE into guest context

[Jan Beulich]

>>> On 08.06.18 at 20:48,  wrote:
> @@ -1646,22 +1637,71 @@ static void vmx_update_guest_cr(struct vcpu *v, 
> unsigned int cr,
>  
>  static void vmx_update_guest_efer(struct vcpu *v)
>  {
> -unsigned long vm_entry_value;
> +unsigned long entry_ctls, guest_efer = v->arch.hvm_vcpu.guest_efer,
> +xen_efer = read_efer();
> +
> +if ( paging_mode_shadow(v->domain) )
> +{
> +/*
> + * When using shadow pagetables, EFER.NX is a Xen-owned bit and is 
> not
> + * under guest control.
> + */
> +guest_efer &= ~EFER_NX;
> +guest_efer |= xen_efer & EFER_NX;
> +}
> +
> +if ( !(v->arch.hvm_vmx.secondary_exec_control &
> +   SECONDARY_EXEC_UNRESTRICTED_GUEST) )

!vmx_unrestricted_guest(v)

> +{
> +/*
> + * When Unrestricted Guest is not enabled in the VMCS, hardware does
> + * not tolerate the LME and LMA settings being different.  As writes
> + * to CR0 are intercepted, it is safe to leave LME clear at this
> + * point, and fix up both LME and LMA when CR0.PG is set.
> + */
> +if ( !(guest_efer & EFER_LMA) )
> +guest_efer &= ~EFER_LME;
> +}
>  
>  vmx_vmcs_enter(v);
>  
> -__vmread(VM_ENTRY_CONTROLS, _entry_value);
> -if ( v->arch.hvm_vcpu.guest_efer & EFER_LMA )
> -vm_entry_value |= VM_ENTRY_IA32E_MODE;
> +/*
> + * The intended guest running mode is derived from VM_ENTRY_IA32E_MODE,
> + * which (architecturally) is the guest's LMA setting.
> + */
> +__vmread(VM_ENTRY_CONTROLS, _ctls);
> +
> +entry_ctls &= ~VM_ENTRY_IA32E_MODE;
> +if ( guest_efer & EFER_LMA )
> +entry_ctls |= VM_ENTRY_IA32E_MODE;
> +
> +__vmwrite(VM_ENTRY_CONTROLS, entry_ctls);
> +
> +/* We expect to use EFER loading in the common case, but... */
> +if ( likely(cpu_has_vmx_efer) )
> +__vmwrite(GUEST_EFER, guest_efer);
> +
> +/* ... on Gen1 VT-x hardware, we have to use MSR load/save lists 
> instead. */
>  else
> -vm_entry_value &= ~VM_ENTRY_IA32E_MODE;
> -__vmwrite(VM_ENTRY_CONTROLS, vm_entry_value);
> +{
> +/*
> + * When the guests choice of EFER matches Xen's, remove the load/save
> + * list entries.  It is unnecessary overhead, especially as this is
> + * expected to be the common case for 64bit guests.
> + */
> +if ( guest_efer == xen_efer )
> +{
> +vmx_del_msr(v, MSR_EFER, VMX_MSR_HOST);
> +vmx_del_msr(v, MSR_EFER, VMX_MSR_GUEST_LOADONLY);
> +}
> +else
> +{
> +vmx_add_msr(v, MSR_EFER, xen_efer, VMX_MSR_HOST);
> +vmx_add_msr(v, MSR_EFER, guest_efer, VMX_MSR_GUEST_LOADONLY);
> +}
> +}
>  
>  vmx_vmcs_exit(v);
> -
> -if ( v == current )
> -write_efer((read_efer() & ~EFER_SCE) |
> -   (v->arch.hvm_vcpu.guest_efer & EFER_SCE));
>  }

As mentioned before, overall this would allow for disabling read intercepts in
certain cases. If you don't want to do this right away that's certainly fine, 
but
could I talk you into at least adding a comment to this effect?

> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -311,6 +311,8 @@ extern u64 vmx_ept_vpid_cap;
>  (vmx_cpu_based_exec_control & CPU_BASED_MONITOR_TRAP_FLAG)
>  #define cpu_has_vmx_pat \
>  (vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_PAT)
> +#define cpu_has_vmx_efer \
> +(vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_EFER)

I think this was asked before, but I'm concerned (of at least the inconsistency)
anyway: cpu_has_vmx_mpx, for example, checks both flags. Of course there's
unlikely to be any hardware with just one of the two features, but what about
buggy virtual environments we might run in?

IOW - if you want to check just one of the two flags here, I think you want to
enforce the dependency in vmx_init_vmcs_config(), clearing the entry control
bit if the exit control one comes out clear from adjust_vmx_controls().

Jan


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

Re: [Xen-devel] [PATCH v5 07/10] arm: add a tiny kconfig configuration

[Julien Grall]

Hi Stefano,

On 12/06/18 01:50, Stefano Stabellini wrote:

On Tue, 5 Jun 2018, Julien Grall wrote:

Hi Stefano,

On 04/06/18 18:24, Stefano Stabellini wrote:

Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
Support only 8 cpus. It only carries non-default options (use make


I don't see where 8 CPUs would only be supported as the default value is 128
cpus.
  
I need to update the commit message reflecting the changes to the patch




olddefconfig to produce a complete .config file).


With all the series I did the following things:
1) copy tiny.config to .config
2) make olddefconfig
3) make menuconfig and select QEMU

After 1) the numbers of CPUs are set to 128. After 3) I would expect the
number of CPUs to go down to 8. Unfortunately this is not the cases.

So your command does not seem to be enough here.


NR_CPUS cannot go down. It is a limitation of Kconfig, similar to the
fact that option cannot be de-selected.

It is not 1) that sets NR_CPUS to 128, it would be 2) above. For this to
work you have to skip 2) and just do:

- copy tiny.config to .config
- make menuconfig and select QEMU


Well I suggested a way during one of our recent chat and I am a bit 
surprised this was not considered here.


For reminder, the way was to provide a makefile target that will select 
tiny and the platform at the same time.


make tiny_defconfig PLAT=qemu

Cheers,






Signed-off-by: Stefano Stabellini 

---
---
   xen/arch/arm/configs/tiny.conf | 43
++
   1 file changed, 43 insertions(+)
   create mode 100644 xen/arch/arm/configs/tiny.conf

diff --git a/xen/arch/arm/configs/tiny.conf b/xen/arch/arm/configs/tiny.conf
new file mode 100644
index 000..e9a5e65
--- /dev/null
+++ b/xen/arch/arm/configs/tiny.conf
@@ -0,0 +1,43 @@
+CONFIG_ARM_64=y


This config targets arm64. So I would name it tiny64.conf.


OK



+CONFIG_ARM=y
+
+#
+# Architecture Features
+#
+# CONFIG_GICV3 is not set
+# CONFIG_MEM_ACCESS is not set
+# CONFIG_SBSA_VUART_CONSOLE is not set
+
+#
+# Common Features
+#
+# CONFIG_TMEM is not set
+
+#
+# Schedulers
+#
+# CONFIG_SCHED_CREDIT2 is not set
+# CONFIG_SCHED_RTDS is not set
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_NULL_DEFAULT=y
+CONFIG_SCHED_DEFAULT="null"
+# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+
+#
+# Device Drivers
+#
+# CONFIG_HAS_NS16550 is not set
+# CONFIG_HAS_CADENCE_UART is not set
+# CONFIG_HAS_MVEBU is not set
+# CONFIG_HAS_PL011 is not set
+# CONFIG_HAS_SCIF is not set
+# CONFIG_ARM_SMMU is not set
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_VERBOSE_DEBUG is not set
+# CONFIG_SCRUB_DEBUG is not set



Cheers,

--
Julien Grall



--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.11] scripts/add_maintainers.pl: Don't call get_maintainers.pl with -f

[Ian Jackson]

Julien Grall writes ("Re: [PATCH for-4.11] scripts/add_maintainers.pl: Don't 
call get_maintainers.pl with -f"):
> On 06/06/18 11:06, Julien Grall wrote:
> > I will commit the patch once we branched.
> 
> I was about to commit but I forgot that I would need a ack from someone 
> in "THE REST".
> 
> Can I get one from either, Andrew, George, Ian, Jan, Tim, Wei,
> Stefano?

Of course.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v1 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

[Julien Grall]

Hi Stefano,

On 12/06/18 00:14, Stefano Stabellini wrote:

On Tue, 5 Jun 2018, Julien Grall wrote:

As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.

A new capability is also allocated for that purpose, and a config
option.

This is part of XSA-263.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Add the switch in this patch rather than the next one.
 - s/supported/required/
---
  xen/arch/arm/Kconfig | 10 +++
  xen/arch/arm/cpuerrata.c | 57 
  xen/include/asm-arm/cpuerrata.h  | 21 +++
  xen/include/asm-arm/cpufeature.h |  3 ++-
  xen/include/asm-arm/smccc.h  |  7 +
  5 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..0e2d027060 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
  Allows a guest to use SBSA Generic UART as a console. The
  SBSA Generic UART implements a subset of ARM PL011 UART.
  
+config ARM_SSBD

+   bool "Speculative Store Bypass Disable" if EXPERT = "y"
+   depends on HAS_ALTERNATIVE
+   default y
+   help
+ This enables mitigation of bypassing of previous stores by speculative
+ loads.
+
+ If unsure, say Y.
+
  endmenu
  
  menu "ARM errata workaround via the alternative framework"

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..aa86c7c0fe 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -235,6 +235,57 @@ static int enable_ic_inv_hardening(void *data)
  
  #endif
  
+#ifdef CONFIG_ARM_SSBD

+
+/*
+ * Assembly code may use the variable directly, so we need to make sure
+ * it fits in a register.
+ */
+DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
+
+static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+bool required;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+/*
+ * The probe function return value is either negative (unsupported
+ * or mitigated), positive (unaffected), or zero (requires
+ * mitigation). We only need to do anything in the last case.
+ */
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
+switch ( (int)res.a0 )
+{
+case ARM_SMCCC_NOT_SUPPORTED:
+return false;
+
+case ARM_SMCCC_NOT_REQUIRED:
+return false;
+
+case ARM_SMCCC_SUCCESS:
+required = true;
+break;
+
+case 1: /* Mitigation not required on this CPU. */
+required = true;
+break;


Why is this required = true when the comment say otherwise, and we
change it to false in the next patch?


It was just a problem on the rebase after you asked to reshuffle the code.

Cheers,


--
Julien Grall

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

[Xen-devel] [OSSTEST PATCH 02/11] cs-adjust-flight: Allow adjusting play flights after start

[Ian Jackson]

Specifically, rather than simply bombing out, if the flight already
has steps, we call dbfl_check again with an empty list of OK
blessings.  dbfl_check will then bomb out, unless the flight's
blessing or intended blessing is `play'.  If it doesn't bomb out, we
print a message.

Signed-off-by: Ian Jackson 
---
 cs-adjust-flight | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index afb81cb..4f036f4 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -465,7 +465,11 @@ sub changes () {
$dbh_tests->prepare("SELECT * FROM steps WHERE flight = ?");
$steps_q->execute($dstflight);
my $step = $steps_q->fetchrow_hashref();
-   die "$dstflight already has steps\n".Dumper($step) if $step;
+   if ($step) {
+   warn "$dstflight already has steps\n".Dumper($step) if $step;
+   $mjobdb->dbfl_check($dstflight,[]);
+   print STDERR "changing flight $dstflight anyway\n";
+   }
 }
 
 @changes = @org_changes;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/altp2m: set access_required properly for all altp2ms

[Razvan Cojocaru]

Thanks for the review!

On 06/12/2018 03:23 PM, Jan Beulich wrote:
 On 11.06.18 at 17:12,  wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -38,6 +38,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
> 
> Not the least to avoid this I think ...
> 
>> @@ -719,6 +720,22 @@ int arch_domain_soft_reset(struct domain *d)
>>  return ret;
>>  }
>>  
>> +void arch_domain_set_access_required(struct domain *d, bool access_required)
> 
> ... this belongs somewhere in x86/mm/.

No problem, I'll move it there.

>> +{
>> +unsigned int i;
>> +
>> +if ( !altp2m_active(d) )
>> +return;
> 
> Hard tab.
Sorry for missing that.

>> +for ( i = 0; i < MAX_ALTP2M; i++ )
>> +{
>> +if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
>> +continue;
> 
> Yet another EPT-specific check outside of EPT code. Why can't you
> check the pointer you use ...
> 
>> +d->arch.altp2m_p2m[i]->access_required = access_required;
> 
> ... here against NULL, and otherwise do the store irrespective
> of the value of d->arch.altp2m_eptp[i]?

No reason, it'll have the same effect. I thought I'd only take care of
the active altp2ms, but the extra effort doesn't buy much indeed.

>> @@ -210,7 +211,7 @@ static int p2m_init_altp2m(struct domain *d)
>>  return -ENOMEM;
>>  }
>>  p2m->p2m_class = p2m_alternate;
>> -p2m->access_required = 1;
>> +p2m->access_required = hostp2m->access_required;
> 
> There must have been a reason to have it start out as 1. You
> mention the fact in the description, but not why it is okay (or
> even necessary) to change it.

If there was one, I can't see what it was. It in any case make altp2ms
behave differently than the hostp2m. The mem_access system has been
designed so that the user can say "this domain should now no longer be
able to continue if there are EPT violatios and there's no vm_event
subscriber attached".

Our application, for one, explicitly _disables_ access_required - so
that it is able to detach from the domain and reattach later. Hence the
surprise when an altp2m-enabled domain crashed when the introspection
agent detached.

Basically, the altp2m behaviour can't be controlled at all here. Maybe
Tamas remembers / knows more about why access_required ended up being 1
always, but it was probably just the quickest way to write the original
patch.

>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -1094,6 +1094,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
>> u_domctl)
>>  domain_pause(d);
>>  p2m_get_hostp2m(d)->access_required =
>>  op->u.access_required.access_required;
>> +arch_domain_set_access_required(d,
>> +op->u.access_required.access_required);
> 
> Perhaps the setting of the host p2m field should move into that
> function as well?

No objection, but should in that case the logic still live in
common/domctl.c (if the only thing the case does is call
arch_domain_set_access_required())?

I thought the common part (setting p2m_get_hostp2m(d)->access_required)
justifies the code remaining in the common/ source file.


Thanks,
Razvan

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

[Xen-devel] [OSSTEST PATCH] seabios: Switch from git:// to https://

[Ian Jackson]

Currently git.seabios.org is down.  https is better anyway.

CC: Anthony PERARD 
Signed-off-by: Ian Jackson 
---
 ap-common | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ap-common b/ap-common
index 5e7cfde..a967ac6 100644
--- a/ap-common
+++ b/ap-common
@@ -47,7 +47,7 @@
 : ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/osstest/rumprun.git}
 : ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/osstest/rumprun.git}
 
-: ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
+: ${TREE_SEABIOS_UPSTREAM:=https://git.seabios.org/seabios.git}
 : ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
 : ${BASE_TREE_SEABIOS:=git://xenbits.xen.org/osstest/seabios.git}
 
-- 
2.1.4


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

Re: [Xen-devel] [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"

[Jiri Denemark]

On Thu, May 24, 2018 at 15:52:55 -0600, Jim Fehlig wrote:
> On 05/24/2018 04:27 AM, Ian Jackson wrote:
> > Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""):
> >> tl;dr:
> >>
> >> I think there is a bug in libvirt's build system which, with
> >> low probability, causes a build failure containing this message:
> >>/usr/bin/ld: cannot find -lvirt
> >>
> >> Complete build logs of two attempts:
> >>
> >>
> >> http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-build.log
> >>
> >>
> >> http://logs.test-lab.xenproject.org/osstest/logs/123096/build-i386-libvirt/6.ts-libvirt-build.log
> > 
> > I have run a number of attempts.  Out of 5 more, 1 succeeded.  So out
> > of a total of 7 attempts, 1 succeeded.  This repro rate is an IMO
> > excellent opportunity to debug this race :-).
> 
> There appears to be a missing dependency between the lockd library and 
> libvirt 
> library, but my autotools skills lack the savvy to find it. Here we see the 
> install command and relinking of lockd.la

I hit the same race twice on aarch64 and ppc64 and I can confirm the
installation phase fails if libvirt.la is installed later than libraries
which link to it. However, the dependencies seem to be set correctly in
the Makefiles. But it looks like they are only honored when linking the
library during the build phase. During make install libvirt.la and
libraries which link to it are installed independently. That is,
install-modLTLIBRARIES does not depend on anything except for the
mod_LTIBRARIES themselves. Thus when libtool decides to relink the
libraries libvirt.la may still be missing at this point. Manually
changing

install-modLTLIBRARIES: $(mod_LTLIBRARIES)

to

install-modLTLIBRARIES: $(mod_LTLIBRARIES) install-libLTLIBRARIES

fixed the problem for me (tested with an artificial delay added to
install-libLTLIBRARIES target), but I have no idea how to persuade
automake to generate something like that for us.

Eric, is my investigation correct and do you have any ideas on how to
fix the race?

Jirka

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

Re: [Xen-devel] [PATCH for-4.11] scripts/add_maintainers.pl: Don't call get_maintainers.pl with -f

[Jan Beulich]

>>> On 12.06.18 at 12:44,  wrote:
> On 06/06/18 11:06, Julien Grall wrote:
>> On 05/06/18 19:26, Lars Kurth wrote:
>>> This change in behaviour was mistakenly introduced in one of the later 
>>> revisions (can't recall which), when we refactored the call to 
>>> get_maintainers.pl
>> 
>> Thank you! Other than that the script is working quite well and save me 
>> time to add all the CCs.
>> 
>> I will commit the patch once we branched.
> 
> I was about to commit but I forgot that I would need a ack from someone 
> in "THE REST".

I'm a little confused, considering the "once we branched" still in context here.

Jan



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

[Xen-devel] [PATCH v3 01/13] xen/arm: domain: Zero the per-vCPU cpu_info

[Julien Grall]

A stack is allocated per vCPU to be used by Xen. The allocation is done
with alloc_xenheap_pages that does not zero the memory returned. However
the top of the stack is containing information that will be used to
store the initial state of the vCPU (see struct cpu_info). Some of the
fields may not be initialized and will lead to use/leak bits of previous
memory in some cases on the first run of vCPU (AFAICT this only happen on
vCPU0 for Dom0).

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v3:
- Add stefano's reviewed-by

Changes in v2:
- Zero only cpu_info
---
 xen/arch/arm/domain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ec0f042bf7..5a2a9a6b83 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -550,6 +550,7 @@ int vcpu_initialise(struct vcpu *v)
 v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
+ STACK_SIZE
- sizeof(struct cpu_info));
+memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info));
 
 memset(>arch.saved_context, 0, sizeof(v->arch.saved_context));
 v->arch.saved_context.sp = (register_t)v->arch.cpu_info;
-- 
2.11.0


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

[Xen-devel] [PATCH v3 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features"

[Julien Grall]

At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making
impossible for the user to unselect it.

Also, it looks like we require to use 'expert = "y"' for showing the
option in expert mode.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/Kconfig | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 0e2d027060..4212c58171 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -83,6 +83,23 @@ config ARM_SSBD
 
  If unsure, say Y.
 
+config HARDEN_BRANCH_PREDICTOR
+   bool "Harden the branch predictor against aliasing attacks" if EXPERT = 
"y"
+   default y
+   help
+ Speculation attacks against some high-performance processors rely on
+ being able to manipulate the branch predictor for a victim context by
+ executing aliasing branches in the attacker context.  Such attacks
+ can be partially mitigated against by clearing internal branch
+ predictor state and limiting the prediction logic in some situations.
+
+ This config option will take CPU-specific actions to harden the
+ branch predictor against aliasing attacks and may rely on specific
+ instruction sequences or control bits being set by the system
+ firmware.
+
+ If unsure, say Y.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
@@ -197,23 +214,6 @@ config ARM64_ERRATUM_834220
 
 endmenu
 
-config HARDEN_BRANCH_PREDICTOR
-   bool "Harden the branch predictor against aliasing attacks" if EXPERT
-   default y
-   help
- Speculation attacks against some high-performance processors rely on
- being able to manipulate the branch predictor for a victim context by
- executing aliasing branches in the attacker context.  Such attacks
- can be partially mitigated against by clearing internal branch
- predictor state and limiting the prediction logic in some situations.
-
- This config option will take CPU-specific actions to harden the
- branch predictor against aliasing attacks and may rely on specific
- instruction sequences or control bits being set by the system
- firmware.
-
- If unsure, say Y.
-
 config ARM64_HARDEN_BRANCH_PREDICTOR
 def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
 
-- 
2.11.0


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

[Xen-devel] [PATCH v3 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263)

[Julien Grall]

Hi all,

This patch series implement the Xen hypervisor side of the "Spectre-v4"
(CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable"
(SSBD).

More information can be found at:
  https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability

For all released Arm Cortex-A that are affected by this issue, then the
preferred mitigation is simply to set a chicken bit in the firmware during
CPU initialization and therefore no change to Xen is required. Other CPUs
may require the chicken bit to be toggled dynamically (for example, when
switching between kernel-mode and hypervisor-mode) and this is achieve by
calling into EL3 via an SMC which has been published as part of the latest
SMCCC specification:
  
https://developer.arm.com/cache-speculation-vulnerability-firmware-specification

as well as an ATF update for the released ARM cores affected by SSBD:
  https://github.com/ARM-software/arm-trusted-firmware/pull/1392

These patches provide the following:
  1. Safe probing of firmware to establish which CPUs in the system
 require calling into EL3 as part of the mitigation
  2. A command-line option to force SSBD mitigation to be always on,
 always off, or dynamically toggled (default) for CPUs that require
 the EL3 call.
  3. An initial implementation of the call via Xen, which exposes the
 mitigation to the guest via an HVC interface.

This patch also provides bug fix and new infrastructure require to implement
the mitigation:
  1. Zeroed each vCPU stack
  2. Provide generic assembly macros
  3. Provide alternative callback (RFC)

A branch can be found with all the patches at:
  https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
  branch ssbd/v3

Cheers,


Julien Grall (13):
  xen/arm: domain: Zero the per-vCPU cpu_info
  xen/arm64: entry: Use named label in guest_sync
  xen/arm: setup: Check errata for boot CPU later on
  xen/arm: Add ARCH_WORKAROUND_2 probing
  xen/arm: Add command line option to control SSBD mitigation
  xen/arm: Add ARCH_WORKAROUND_2 support for guests
  xen/arm: Simplify alternative patching of non-writable region
  xen/arm: alternatives: Add dynamic patching feature
  xen/arm64: Add generic assembly macros
  xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
  xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture
features"
  xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID
  xen/arm: Avoid to use current everywhere in enter_hypervisor_head

 docs/misc/xen-command-line.markdown |  18 +
 xen/arch/arm/Kconfig|  44 +++
 xen/arch/arm/alternative.c  |  86 +++--
 xen/arch/arm/arm64/asm-offsets.c|   2 +
 xen/arch/arm/arm64/entry.S  |  48 +++-
 xen/arch/arm/cpuerrata.c| 150 
 xen/arch/arm/domain.c   |   9 +++
 xen/arch/arm/setup.c|   8 +-
 xen/arch/arm/traps.c|  32 ++--
 xen/arch/arm/vsmc.c |  37 +
 xen/include/asm-arm/alternative.h   |  44 +--
 xen/include/asm-arm/arm64/macros.h  |  25 ++
 xen/include/asm-arm/cpuerrata.h |  42 ++
 xen/include/asm-arm/cpufeature.h|   3 +-
 xen/include/asm-arm/current.h   |   6 +-
 xen/include/asm-arm/macros.h|   2 +-
 xen/include/asm-arm/smccc.h |  13 +++-
 17 files changed, 491 insertions(+), 78 deletions(-)
 create mode 100644 xen/include/asm-arm/arm64/macros.h

-- 
2.11.0


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

[Xen-devel] [PATCH v3 09/13] xen/arm64: Add generic assembly macros

[Julien Grall]

Add assembly macros to simplify assembly code:
- adr_cpu_info: Get the address to the current cpu_info structure
- ldr_this_cpu: Load a per-cpu value

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/include/asm-arm/arm64/macros.h | 25 +
 xen/include/asm-arm/macros.h   |  2 +-
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/asm-arm/arm64/macros.h

diff --git a/xen/include/asm-arm/arm64/macros.h 
b/xen/include/asm-arm/arm64/macros.h
new file mode 100644
index 00..9c5e676b37
--- /dev/null
+++ b/xen/include/asm-arm/arm64/macros.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_ARM_ARM64_MACROS_H
+#define __ASM_ARM_ARM64_MACROS_H
+
+/*
+ * @dst: Result of get_cpu_info()
+ */
+.macro  adr_cpu_info, dst
+add \dst, sp, #STACK_SIZE
+and \dst, \dst, #~(STACK_SIZE - 1)
+sub \dst, \dst, #CPUINFO_sizeof
+.endm
+
+/*
+ * @dst: Result of READ_ONCE(per_cpu(sym, smp_processor_id()))
+ * @sym: The name of the per-cpu variable
+ * @tmp: scratch register
+ */
+.macro  ldr_this_cpu, dst, sym, tmp
+ldr \dst, =per_cpu__\sym
+mrs \tmp, tpidr_el2
+ldr \dst, [\dst, \tmp]
+.endm
+
+#endif /* __ASM_ARM_ARM64_MACROS_H */
+
diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h
index 5d837cb38b..1d4bb41d15 100644
--- a/xen/include/asm-arm/macros.h
+++ b/xen/include/asm-arm/macros.h
@@ -8,7 +8,7 @@
 #if defined (CONFIG_ARM_32)
 # include 
 #elif defined(CONFIG_ARM_64)
-/* No specific ARM64 macros for now */
+# include 
 #else
 # error "unknown ARM variant"
 #endif
-- 
2.11.0


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

[Xen-devel] [PATCH v3 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

[Julien Grall]

Using current is fairly expensive, so save up into a variable.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/traps.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 315fc61f77..bde303261e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 {
 if ( guest_mode(regs) )
 {
+struct vcpu *v = current;
+
 /* If the guest has disabled the workaround, bring it back on. */
-if ( needs_ssbd_flip(current) )
+if ( needs_ssbd_flip(v) )
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
 
 /*
@@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
  * (alias of HCR.VA) is cleared to 0."
  */
-if ( current->arch.hcr_el2 & HCR_VA )
-current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
+if ( v->arch.hcr_el2 & HCR_VA )
+v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
 
 #ifdef CONFIG_NEW_VGIC
 /*
@@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  * TODO: Investigate whether this is necessary to do on every
  * trap and how it can be optimised.
  */
-vtimer_update_irqs(current);
-vcpu_update_evtchn_irq(current);
+vtimer_update_irqs(v);
+vcpu_update_evtchn_irq(v);
 #endif
 
-vgic_sync_from_lrs(current);
+vgic_sync_from_lrs(v);
 }
 }
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 1/2] VT-d: re-phrase logic in vtd_set_hwdom_mapping() for clarity

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 11 June 2018 11:35
> To: Roger Pau Monne 
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Andrew Cooper
> ; Tim (Xen.org) ; George
> Dunlap ; Julien Grall ;
> Jan Beulich ; Ian Jackson ;
> xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH 1/2] VT-d: re-phrase logic in
> vtd_set_hwdom_mapping() for clarity
> 
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 11 June 2018 11:31
> > To: Paul Durrant 
> > Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> > Stefano Stabellini ; Wei Liu ;
> > George Dunlap ; Andrew Cooper
> > ; Ian Jackson ; Tim
> > (Xen.org) ; Julien Grall ; Jan Beulich
> > 
> > Subject: Re: [Xen-devel] [PATCH 1/2] VT-d: re-phrase logic in
> > vtd_set_hwdom_mapping() for clarity
> >
> > On Fri, Jun 08, 2018 at 04:30:29PM +0100, Paul Durrant wrote:
> > > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-
> > command-line.markdown
> > > index 8712a833a2..6beb28dada 100644
> > > --- a/docs/misc/xen-command-line.markdown
> > > +++ b/docs/misc/xen-command-line.markdown
> > > @@ -1212,8 +1212,8 @@ wait descriptor timed out', try increasing this
> > value.
> > >
> > >  Use this to work around firmware issues providing incorrect RMRR
> entries.
> > >  Rather than only mapping RAM pages for IOMMU accesses for Dom0,
> with
> > this
> > > -option all pages not marked as unusable in the E820 table will get a
> > mapping
> > > -established.
> > > +option all pages up to and including 4GB, not marked as unusable in the
> > > +E820 table, will get a mapping established.
> >
> > Sorry, I've reviewed the patches in the wrong order. You can ignore
> > the comments I've made related to this in patch 2.
> >
> > >  ### irq\_ratelimit (x86)
> > >  > `= `
> > > diff --git a/xen/drivers/passthrough/vtd/x86/vtd.c
> > b/xen/drivers/passthrough/vtd/x86/vtd.c
> > > index 88a60b3307..5c440ba183 100644
> > > --- a/xen/drivers/passthrough/vtd/x86/vtd.c
> > > +++ b/xen/drivers/passthrough/vtd/x86/vtd.c
> > > @@ -118,22 +118,26 @@ void __hwdom_init
> > vtd_set_hwdom_mapping(struct domain *d)
> > >
> > >  for ( i = 0; i < top; i++ )
> > >  {
> > > +unsigned long pfn = pdx_to_pfn(i);
> > > +bool map;
> > >  int rc = 0;
> > >
> > >  /*
> > > - * Set up 1:1 mapping for dom0. Default to use only conventional
> RAM
> > > - * areas and let RMRRs include needed reserved regions. When set,
> > the
> > > - * inclusive mapping maps in everything below 4GB except unusable
> > > - * ranges.
> > > + * Set up 1:1 mapping for dom0. Default to include only
> > > + * conventional RAM areas and let RMRRs include needed reserved
> > > + * regions. When set, the inclusive mapping maps in every pfn up
> > > + * to and including 4GB except those that fall in unusable 
> > > ranges.
> > >   */
> > > -unsigned long pfn = pdx_to_pfn(i);
> > > +if ( iommu_inclusive_mapping &&
> > > + pfn <= (0xUL >> PAGE_SHIFT) )
> >
> > Please use GB(4) here for clarity.
> 
> That would be better. I left it since that's what the old code used but it 
> I'll
> change this one and the one below.

Actually since you pointed this out that my reasoning before was wrong. Because 
the comparison was with 0x >> PAGE_SHIFT (i.e. GB(4) - 1), the 
inclusive map does not include GB(4) itself... so the documentation was correct.

  Paul

> 
> >
> > > +map = !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE);
> > > +else
> > > +map = page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL);
> > > +
> > > +if ( !map )
> > > +continue;
> > >
> > > -if ( pfn > (0xUL >> PAGE_SHIFT) ?
> > > - (!mfn_valid(_mfn(pfn)) ||
> > > -  !page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL)) :
> > > - iommu_inclusive_mapping ?
> > > - page_is_ram_type(pfn, RAM_TYPE_UNUSABLE) :
> > > - !page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) )
> > > +if ( pfn > (0xUL >> PAGE_SHIFT) && !mfn_valid(_mfn(pfn)) 
> > > )
> >
> > I would maybe do this check before the page_is_ram_type one, so that
> > you can discard invalid mfns earlier.
> 
> True.
> 
>   Paul
> 
> >
> > Thanks, Roger.
> 
> ___
> 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

[Xen-devel] [distros-debian-sid test] 74842: tolerable FAIL

[Platform Team regression test user]

flight 74842 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74842/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-amd64-sid-netboot-pvgrub 11 guest-start fail blocked in 74777
 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install   fail like 74777
 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 74777
 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install  fail like 74777

baseline version:
 flight   74777

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub pass
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


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

Re: [Xen-devel] [PATCH v2 5/9] x86/vmx: Improvements to LBR MSR handling

[Jan Beulich]

>>> On 12.06.18 at 10:51,  wrote:
> On 12/06/2018 09:15, Jan Beulich wrote:
> On 08.06.18 at 20:48,  wrote:
>>> @@ -3106,14 +3104,13 @@ static int vmx_msr_write_intercept(unsigned int 
>>> msr, 
> uint64_t msr_content)
>>>  for ( ; (rc == 0) && lbr->count; lbr++ )
>>>  for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
>>>  if ( (rc = vmx_add_guest_msr(v, lbr->base + i)) == 0 )
>>> -{
>>>  vmx_clear_msr_intercept(v, lbr->base + i, 
> VMX_MSR_RW);
>>> -if ( lbr_tsx_fixup_needed )
>>> -v->arch.hvm_vmx.lbr_fixup_enabled |= 
> FIXUP_LBR_TSX;
>>> -if ( bdw_erratum_bdf14_fixup_needed )
>>> -v->arch.hvm_vmx.lbr_fixup_enabled |=
>>> -FIXUP_BDW_ERRATUM_BDF14;
>>> -}
>>> +
>>> +v->arch.hvm_vmx.lbr_flags |= LBR_MSRS_INSERTED;
>>> +if ( lbr_tsx_fixup_needed )
>>> +v->arch.hvm_vmx.lbr_flags |= LBR_FIXUP_TSX;
>>> +if ( bdw_erratum_bdf14_fixup_needed )
>>> +v->arch.hvm_vmx.lbr_flags |= LBR_FIXUP_BDF14;
>> Note how the setting of the flags previously depended on
>> vmx_add_guest_msr() having returned success at least once.
> 
> And?
> 
> Unless this sequence returns fully successfully, we throw #MC into the
> guest without setting any kind of vMCE state.  It might be the least bad
> option we have available, but its also not reasonable to expect the
> guest to survive.
> 
> The two ways to fail are ENOMEM which E2BIG.  The former is going to be
> causing other forms of chaos, and the latter isn't going to occur in
> practice because current codepaths in Xen use a maximum of ~40 or the
> 256 available slots.  If in the unlikely case that we fail with ENOMEM
> on the first entry, all the fixup logic gets short circuited due to the
> missing memory allocation (so practically 0 extra overhead), and the
> guest will still malfunction.
> 
> The error handling here is sufficiently poor that I'm not worried about
> changing one minor corner case.  I'm actually debating whether it would
> be better to make the allocation at vmcs construction time, to avoid
> runtime out-of-memory issues.

With further improved MSR handling down the road, I assume we'll
have some entries in the list in almost all cases, so yes, I think that
would be desirable.

>>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
>>> @@ -156,7 +156,12 @@ struct arch_vmx_struct {
>>>  /* Are we emulating rather than VMENTERing? */
>>>  uint8_t  vmx_emulate;
>>>  
>>> -uint8_t  lbr_fixup_enabled;
>>> +/* Flags for LBR MSRs in the load/save lists. */
>>> +#define LBR_MSRS_INSERTED  (1u << 0)
>>> +#define LBR_FIXUP_TSX  (1u << 1)
>>> +#define LBR_FIXUP_BDF14(1u << 2)
>>> +#define LBR_FIXUP_MASK (LBR_FIXUP_TSX | LBR_FIXUP_BDF14)
>>> +uint8_t  lbr_flags;
>> I'm not overly happy with these getting moved to a non-private header,
>> but I assume you need to use the new flag in vmcs.c in a later patch.
>> Let's hope no other LBR_-prefixed names appear elsewhere in the code.
> 
> No - no use in a later patch.  They are moved here so they are next to
> the data field they are used for.  The previous code having random
> defines remote from, and not obviously linked with, this data field is
> detrimental to code quality and clarity.

A comment at both sites providing the link would already help. Just
like I would always advocate for struct-s to be fully declared locally only
when they're used in just a single source file, I'd also prefer #define-s
to have as little visibility as possible. Anyway - that's something to be
decided by the VMX maintainers in this specific case.

Jan



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

Re: [Xen-devel] [PATCH v2 5/9] x86/vmx: Improvements to LBR MSR handling

[Andrew Cooper]

On 12/06/2018 09:15, Jan Beulich wrote:
 On 08.06.18 at 20:48,  wrote:
>> @@ -3106,14 +3104,13 @@ static int vmx_msr_write_intercept(unsigned int msr, 
>> uint64_t msr_content)
>>  for ( ; (rc == 0) && lbr->count; lbr++ )
>>  for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
>>  if ( (rc = vmx_add_guest_msr(v, lbr->base + i)) == 0 )
>> -{
>>  vmx_clear_msr_intercept(v, lbr->base + i, 
>> VMX_MSR_RW);
>> -if ( lbr_tsx_fixup_needed )
>> -v->arch.hvm_vmx.lbr_fixup_enabled |= 
>> FIXUP_LBR_TSX;
>> -if ( bdw_erratum_bdf14_fixup_needed )
>> -v->arch.hvm_vmx.lbr_fixup_enabled |=
>> -FIXUP_BDW_ERRATUM_BDF14;
>> -}
>> +
>> +v->arch.hvm_vmx.lbr_flags |= LBR_MSRS_INSERTED;
>> +if ( lbr_tsx_fixup_needed )
>> +v->arch.hvm_vmx.lbr_flags |= LBR_FIXUP_TSX;
>> +if ( bdw_erratum_bdf14_fixup_needed )
>> +v->arch.hvm_vmx.lbr_flags |= LBR_FIXUP_BDF14;
> Note how the setting of the flags previously depended on
> vmx_add_guest_msr() having returned success at least once.

And?

Unless this sequence returns fully successfully, we throw #MC into the
guest without setting any kind of vMCE state.  It might be the least bad
option we have available, but its also not reasonable to expect the
guest to survive.

The two ways to fail are ENOMEM which E2BIG.  The former is going to be
causing other forms of chaos, and the latter isn't going to occur in
practice because current codepaths in Xen use a maximum of ~40 or the
256 available slots.  If in the unlikely case that we fail with ENOMEM
on the first entry, all the fixup logic gets short circuited due to the
missing memory allocation (so practically 0 extra overhead), and the
guest will still malfunction.

The error handling here is sufficiently poor that I'm not worried about
changing one minor corner case.  I'm actually debating whether it would
be better to make the allocation at vmcs construction time, to avoid
runtime out-of-memory issues.

>
>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
>> @@ -156,7 +156,12 @@ struct arch_vmx_struct {
>>  /* Are we emulating rather than VMENTERing? */
>>  uint8_t  vmx_emulate;
>>  
>> -uint8_t  lbr_fixup_enabled;
>> +/* Flags for LBR MSRs in the load/save lists. */
>> +#define LBR_MSRS_INSERTED  (1u << 0)
>> +#define LBR_FIXUP_TSX  (1u << 1)
>> +#define LBR_FIXUP_BDF14(1u << 2)
>> +#define LBR_FIXUP_MASK (LBR_FIXUP_TSX | LBR_FIXUP_BDF14)
>> +uint8_t  lbr_flags;
> I'm not overly happy with these getting moved to a non-private header,
> but I assume you need to use the new flag in vmcs.c in a later patch.
> Let's hope no other LBR_-prefixed names appear elsewhere in the code.

No - no use in a later patch.  They are moved here so they are next to
the data field they are used for.  The previous code having random
defines remote from, and not obviously linked with, this data field is
detrimental to code quality and clarity.

As for namespacing, we could go with a VMX_ prefix, but there is no
equivalent needed elsewhere, so the chances of having problems are very low.

~Andrew

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

[Xen-devel] [ovmf baseline-only test] 74855: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74855 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74855/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a05a8a5aa17da4bc7144706a9931d68beec1a61f
baseline version:
 ovmf eb5943134630292db2c14346b5d94eab0b72314f

Last test of basis74839  2018-06-10 07:54:36 Z1 days
Testing same since74855  2018-06-11 16:23:52 Z0 days1 attempts


People who touched revisions under test:
  Leo Duran 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit a05a8a5aa17da4bc7144706a9931d68beec1a61f
Author: Leo Duran 
Date:   Fri May 25 03:07:30 2018 +0800

MdeModulePkg/Library/BaseSerialPortLib16550: Ensure FIFO Polled Mode

Put the UART in FIFO Polled Mode by clearing IER after setting FCR.
Also, add comments to show DLAB state for registers 0 and 1.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leo Duran 
Cc: Star Zeng 
CC: Eric Dong 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Star Zeng 

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

Re: [Xen-devel] [PATCH v2 6/9] x86/vmx: Pass an MSR value into vmx_msr_add()

[Jan Beulich]

>>> On 08.06.18 at 20:48,  wrote:
> The main purpose of this change is to allow us to set a specific MSR value,
> without needing to know whether there is already a load/save list slot for it.
> 
> Previously, callers wanting this property needed to call both vmx_add_*_msr()
> and vmx_write_*_msr() to cover both cases, and there are no callers which want
> the old behaviour of being a no-op if an entry already existed for the MSR.
> 
> As a result of this API improvement, the default value for guest MSRs need not
> be 0, and the default for host MSRs need not be passed via hardware register.
> In practice, this cleans up the VPMU allocation logic, and avoids an MSR read
> as part of vcpu construction.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

[Jan Beulich]

>>> On 08.06.18 at 20:48,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1452,6 +1452,74 @@ int vmx_add_msr(struct vcpu *v, uint32_t msr, uint64_t 
> val,
>  return rc;
>  }
>  
> +int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type)
> +{
> +struct arch_vmx_struct *vmx = >arch.hvm_vmx;
> +struct vmx_msr_entry *start = NULL, *ent, *end;
> +unsigned int substart, subend, total;
> +
> +ASSERT(v == current || !vcpu_runnable(v));
> +
> +switch ( type )
> +{
> +case VMX_MSR_HOST:
> +start= vmx->host_msr_area;
> +substart = 0;
> +subend   = vmx->host_msr_count;
> +total= subend;
> +break;
> +
> +case VMX_MSR_GUEST:
> +start= vmx->msr_area;
> +substart = 0;
> +subend   = vmx->msr_save_count;
> +total= vmx->msr_load_count;
> +break;
> +
> +case VMX_MSR_GUEST_LOADONLY:
> +start= vmx->msr_area;
> +substart = vmx->msr_save_count;
> +subend   = vmx->msr_load_count;
> +total= subend;
> +break;
> +
> +default:
> +ASSERT_UNREACHABLE();
> +}
> +
> +if ( !start )
> +return -ESRCH;

I'm pretty sure not all gcc versions we support are capable of recognizing
that substart, subend, and total can't be used uninitialized due to this
return path, without there also being a return in after default: - I'm not
sure though whether adding that return or initializers might be the
better approach towards addressing this. At least for substart an
initializer (of zero) would allow dropping two other lines of code.

> +end = start + total;
> +ent = locate_msr_entry(start + substart, start + subend, msr);
> +
> +if ( (ent == end) || (ent->index != msr) )
> +return -ESRCH;
> +
> +memmove(ent, ent + 1, sizeof(*ent) * (end - ent));

Aren't you running over the end of the array by 1 entry here?

> +vmx_vmcs_enter(v);
> +
> +switch ( type )
> +{
> +case VMX_MSR_HOST:
> +__vmwrite(VM_EXIT_MSR_LOAD_COUNT, vmx->host_msr_count--);
> +break;
> +
> +case VMX_MSR_GUEST:
> +__vmwrite(VM_EXIT_MSR_STORE_COUNT, vmx->msr_save_count--);
> +
> +/* Fallthrough */
> +case VMX_MSR_GUEST_LOADONLY:
> +__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, vmx->msr_load_count--);
> +break;
> +}

Don't you want pre-decrements in all of these?

Jan



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

Re: [Xen-devel] [PATCH v2 9/9] x86/vmx: Don't leak EFER.NXE into guest context

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, June 9, 2018 2:49 AM
> 
> Intel hardware only uses 4 bits in MSR_EFER.  Changes to LME and LMA are
> handled automatically via the VMENTRY_CTLS.IA32E_MODE bit.
> 
> SCE is handled by ad-hoc logic in context_switch(),
> vmx_restore_guest_msrs()
> and vmx_update_guest_efer(), and works by altering the host SCE value to
> match
> the setting the guest wants.  This works because, in HVM vcpu context, Xen
> never needs to execute a SYSCALL or SYSRET instruction.
> 
> However, NXE has never been context switched.  Unlike SCE, NXE cannot be
> context switched at vcpu boundaries because disabling NXE makes PTE.NX
> bits
> reserved and cause a pagefault when encountered.  This means that the
> guest
> always has Xen's setting in effect, irrespective of the bit it can see and
> modify in its virtualised view of MSR_EFER.
> 
> This isn't a major problem for production operating systems because they,
> like
> Xen, always turn the NXE on when it is available.  However, it does have an
> observable effect on which guest PTE bits are valid, and whether
> PFEC_insn_fetch is visible in a #PF error code.
> 
> Second generation VT-x hardware has host and guest EFER fields in the
> VMCS,
> and support for loading and saving them automatically.  First generation
> VT-x
> hardware needs to use MSR load/save lists to cause an atomic switch of
> MSR_EFER on vmentry/exit.
> 
> Therefore we update vmx_init_vmcs_config() to find and use guest/host
> EFER
> support when available (and MSR load/save lists on older hardware) and
> drop
> all ad-hoc alteration of SCE.
> 
> There are two minor complications when selecting the EFER setting:
>  * For shadow guests, NXE is a paging setting and must remain under host
>control, but this is fine as Xen also handles the pagefaults.
>  * When the Unrestricted Guest control is clear, hardware doesn't tolerate
> LME
>and LMA being different.  This doesn't matter in practice as we intercept
>all writes to CR0 and reads from MSR_EFER, so can provide architecturally
>consistent behaviour from the guests point of view.
> 
> With changing how EFER is loaded, vmcs_dump_vcpu() needs adjusting.
> Read EFER
> from the appropriate information source, and identify when dumping the
> guest
> EFER value which source was used.
> 
> As a result of fixing EFER context switching, we can remove the Intel-special
> case from hvm_nx_enabled() and let guest_walk_tables() work with the
> real
> guest paging settings.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
> Reviewed-by: Tim Deegan 

Reviewed-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs

[Jan Beulich]

>>> On 12.06.18 at 02:41,  wrote:
> On Wed, 6 Jun 2018, Jan Beulich wrote:
>> >>> On 05.06.18 at 19:52,  wrote:
>> 
>> > 
>> > On 04/06/18 18:23, Stefano Stabellini wrote:
>> >> Hi all,
>> >> 
>> >> This patch series is the first step toward building a small certifiable
>> >> Xen hypervisor for ARM boards.
>> >> 
>> >> First, the series makes a few changes to allow disabling more kconfig
>> >> options: most of them already exist but cannot be disabled.
>> >> 
>> >> Then, it introduces a reference kconfig for Renesas RCar (due to popular
>> >> demand, candidate for certifications), Xilinx MPSoC, and for QEMU
>> >> aarch64 (not for certifications, but useful for debugging).
>> >> 
>> >> The last patch in the series adds a convenient cloc target to count the
>> >> total lines of code of the source files built.
>> >> 
>> >> As a consequence of these changes, some options will become user-visible
>> >> and not dependent on CONFIG_EXPERT. It does not mean that Xen Project
>> >> will security support all possible combinations of kconfig options.
>> >> Instead, there will be a small set of pre-canned configurations that
>> >> will be supported.  See: https://marc.info/?l=xen-devel=152424389512432 
>> > 
>> > George, Ian, Jan, shall SUPPORT.MD be updated to reflect the Kconfig 
>> > changes?
>> > 
>> > I am mostly thinking about the board support and the fact that more 
>> > options on Arm are selectable by the users.
>> 
>> I think that would be very desirable, yes.
> 
> Do you want me to add a patch for that to this series, or should I do it
> separately?

I think such a doc change should be right in a particular patch making
things user selectable.

Jan



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

Re: [Xen-devel] 4.11.0 RC1 panic

[Jan Beulich]

>>> On 10.06.18 at 12:57,  wrote:
> (XEN) Xen call trace:
> (XEN)[] mm.c#dec_linear_entries+0x12/0x20
> (XEN)[] mm.c#_put_page_type+0x13e/0x350
> (XEN)[] _spin_lock+0xd/0x50
> (XEN)[] mm.c#put_page_from_l2e+0xdf/0x110
> (XEN)[] free_page_type+0x2f9/0x790
> (XEN)[] mm.c#_put_page_type+0x107/0x350
> (XEN)[] put_page_type_preemptible+0xf/0x10
> (XEN)[] domain.c#relinquish_memory+0xab/0x460
> (XEN)[] domain_relinquish_resources+0x203/0x290
> (XEN)[] domain_kill+0xbd/0x150
> (XEN)[] do_domctl+0x7d3/0x1a90
> (XEN)[] do_domctl+0/0x1a90
> (XEN)[] pv_hypercall+0x1f5/0x430
> (XEN)[] lstar_enter+0xa2/0x120
> (XEN)[] lstar_enter+0xae/0x120
> (XEN)[] lstar_enter+0xa2/0x120
> (XEN)[] lstar_enter+0xae/0x120
> (XEN)[] lstar_enter+0xa2/0x120
> (XEN)[] lstar_enter+0xae/0x120
> (XEN)[] lstar_enter+0x10c/0x120

Let's focus on this scenario for now, as it is under better (timing) control
on the Xen side. Below is a first debugging patch which
- avoids the ASSERT() in question, instead triggering a printk(), in the hope
  that the data logged and/or other ASSERT()s shed some additional light
  on the situation
- logs cleanup activity (this is likely to be quite chatty, so be sure you set
  up large enough internal buffers)

Ideally, if no other ASSERT() triggers as a result of the bypassed one,
you'd try to catch more than a single instance of the problem, so we can
see a possible pattern (if there is one). A simplistic first XTF test I've
created based on your description of the L2 handling model in NetBSD
did not trigger the interesting printk(), but at least that way I've been
able to see that the domain cleanup logging produces useful data.

At the very least I hope that with this we can derive whether the
root of the problem is at page table teardown / cleanup time, or with
management of live ones.

Jan

--- unstable.orig/xen/arch/x86/domain.c
+++ unstable/xen/arch/x86/domain.c
@@ -1872,6 +1872,7 @@ static int relinquish_memory(
 
 while ( (page = page_list_remove_head(list)) )
 {
+bool log = false;//temp
 /* Grab a reference to the page so it won't disappear from under us. */
 if ( unlikely(!get_page(page, d)) )
 {
@@ -1880,6 +1881,10 @@ static int relinquish_memory(
 continue;
 }
 
+if(is_pv_32bit_domain(d) && PGT_type_equal(page->u.inuse.type_info, 
PGT_l2_page_table)) {//temp
+ printk("d%d:%"PRI_mfn": %lx:%d\n", d->domain_id, mfn_x(page_to_mfn(page)), 
page->u.inuse.type_info, page->linear_pt_count);
+ log = true;
+}
 if ( test_and_clear_bit(_PGT_pinned, >u.inuse.type_info) )
 ret = put_page_and_type_preemptible(page);
 switch ( ret )
@@ -1921,7 +1926,13 @@ static int relinquish_memory(
 if ( likely(y == x) )
 {
 /* No need for atomic update of type_info here: noone else 
updates it. */
-switch ( ret = free_page_type(page, x, 1) )
+//tempswitch ( ret = free_page_type(page, x, 1) )
+ret = free_page_type(page, x, 1);//temp
+if(log) {//temp
+ printk("%"PRI_mfn" -> %lx:%d (%d,%d,%d)\n", mfn_x(page_to_mfn(page)), 
page->u.inuse.type_info,
+page->linear_pt_count, ret, page->nr_validated_ptes, 
page->partial_pte);
+}
+switch(ret)//temp
 {
 case 0:
 break;
--- unstable.orig/xen/arch/x86/mm.c
+++ unstable/xen/arch/x86/mm.c
@@ -705,12 +705,19 @@ static bool inc_linear_entries(struct pa
 return true;
 }
 
-static void dec_linear_entries(struct page_info *pg)
+//temp static void dec_linear_entries(struct page_info *pg)
+static const struct domain*dec_linear_entries(struct page_info*pg)//temp
 {
 typeof(pg->linear_pt_count) oc;
 
 oc = arch_fetch_and_add(>linear_pt_count, -1);
+{//temp
+ const struct domain*owner = page_get_owner(pg);
+ if(oc <= 0 && is_pv_32bit_domain(owner))
+  return owner;
+}
 ASSERT(oc > 0);
+return NULL;//temp
 }
 
 static bool inc_linear_uses(struct page_info *pg)
@@ -2617,8 +2624,15 @@ static int _put_final_page_type(struct p
 {
 if ( ptpg && PGT_type_equal(type, ptpg->u.inuse.type_info) )
 {
+const struct domain*d;//temp
 dec_linear_uses(page);
+if((d = ({//temp
 dec_linear_entries(ptpg);
+})) != NULL) {//temp
+ printk("d%d: %"PRI_mfn":%lx:%d -> %"PRI_mfn":%lx:%d\n", d->domain_id,
+mfn_x(page_to_mfn(ptpg)), ptpg->u.inuse.type_info, 
ptpg->linear_pt_count,
+mfn_x(page_to_mfn(page)), page->u.inuse.type_info, 
page->linear_pt_count);
+}
 }
 ASSERT(!page->linear_pt_count || page_get_owner(page)->is_dying);
 set_tlbflush_timestamp(page);
@@ -2704,8 +2718,15 @@ static int _put_page_type(struct page_in
 
 if ( ptpg && PGT_type_equal(x, ptpg->u.inuse.type_info) )
 {
+const struct domain*d;//temp
 dec_linear_uses(page);
+if((d = ({//temp
 dec_linear_entries(ptpg);
+})) != 

Re: [Xen-devel] [PATCH v2 4/9] x86/vmx: Support remote access to the MSR lists

[Jan Beulich]

>>> On 08.06.18 at 20:48,  wrote:
> At the moment, all modifications of the MSR lists are in current context.
> However, future changes may need to put MSR_EFER into the lists from domctl
> hypercall context.
> 
> Plumb a struct vcpu parameter down through the infrastructure, and use
> vmx_vmcs_{enter,exit}() for safe access to the VMCS in vmx_add_msr().  Use
> assertions to ensure that access is either in current context, or while the
> vcpu is paused.
> 
> Note these expectations beside the fields in arch_vmx_struct, and reorder the
> fields to avoid unnecessary padding.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

[Xen-devel] [xen-4.8-testing test] 124070: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 124070 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124070/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm  broken
 build-armhf-xsm   5 host-build-prep  fail REGR. vs. 123091
 build-i386-pvops  6 kernel-build   fail in 123844 REGR. vs. 123091
 build-armhf   6 xen-build  fail in 123844 REGR. vs. 123091

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-credit2   7 xen-boot fail in 123701 pass in 124070
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail in 123701 pass 
in 124070
 test-amd64-amd64-livepatch7 xen-boot fail in 123701 pass in 124070
 test-amd64-amd64-pair   10 xen-boot/src_host fail in 123701 pass in 124070
 test-amd64-amd64-pair   11 xen-boot/dst_host fail in 123701 pass in 124070
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail in 123701 pass in 124070
 test-amd64-i386-rumprun-i386  7 xen-boot fail in 123701 pass in 124070
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail in 123701 pass in 124070
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail in 123701 pass in 
124070
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail in 123701 pass in 124070
 test-amd64-i386-libvirt-xsm   7 xen-boot fail in 123701 pass in 124070
 test-amd64-i386-migrupgrade 10 xen-boot/src_host fail in 123701 pass in 124070
 test-amd64-i386-migrupgrade 11 xen-boot/dst_host fail in 123701 pass in 124070
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail in 123701 pass in 124070
 test-xtf-amd64-amd64-37 xen-boot fail in 123844 pass in 124070
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
123701
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 123844

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
123844 n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 123844 n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
123844 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 
123844 n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked in 123844 n/a
 build-armhf-libvirt   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)blocked in 123844 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-pair  1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  blocked in 123844 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
123844 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 123844 n/a
 

Re: [Xen-devel] [PATCH v1 05/13] xen/arm: Add command line option to control SSBD mitigation

[Julien Grall]

Hi Stefano,

On 12/06/18 00:15, Stefano Stabellini wrote:

On Tue, 5 Jun 2018, Julien Grall wrote:

  /*
   * Assembly code may use the variable directly, so we need to make sure
   * it fits in a register.
@@ -251,19 +286,17 @@ static bool has_ssbd_mitigation(const struct 
arm_cpu_capabilities *entry)
  if ( smccc_ver < SMCCC_VERSION(1, 1) )
  return false;
  
-/*

- * The probe function return value is either negative (unsupported
- * or mitigated), positive (unaffected), or zero (requires
- * mitigation). We only need to do anything in the last case.
- */
  arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
+


spurious change


It just belongs to the previous patch. This is due to the code 
reshuffling you requested.


[...]


diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index e628d3ff56..7fbb3dc0be 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
  
  #undef CHECK_WORKAROUND_HELPER
  
+enum ssbd_state

+{
+ARM_SSBD_UNKNOWN,
+ARM_SSBD_FORCE_DISABLE,
+ARM_SSBD_RUNTIME,
+ARM_SSBD_FORCE_ENABLE,
+ARM_SSBD_MITIGATED,
+};
+
  #ifdef CONFIG_ARM_SSBD
  
  #include 
  
+extern enum ssbd_state ssbd_state;

+
+static inline enum ssbd_state get_ssbd_state(void)
+{
+return ssbd_state;
+}
+
  DECLARE_PER_CPU(register_t, ssbd_callback_required);
  
  static inline bool cpu_require_ssbd_mitigation(void)

@@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
  return false;
  }
  
+static inline enum ssbd_state get_sbdd_state(void)


the mistype is still present


Fixed now.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.11] scripts/add_maintainers.pl: Don't call get_maintainers.pl with -f

[Julien Grall]

On 12/06/18 12:18, Jan Beulich wrote:

On 12.06.18 at 12:44,  wrote:

On 06/06/18 11:06, Julien Grall wrote:

On 05/06/18 19:26, Lars Kurth wrote:

This change in behaviour was mistakenly introduced in one of the later
revisions (can't recall which), when we refactored the call to
get_maintainers.pl


Thank you! Other than that the script is working quite well and save me
time to add all the CCs.

I will commit the patch once we branched.


I was about to commit but I forgot that I would need a ack from someone
in "THE REST".


I'm a little confused, considering the "once we branched" still in context here.


To give the full story, the e-mail was written when staging had a commit 
moratorium for branching. However, we didn't branch and the commit 
moratorium was lifted. Because the patch is targeting Xen 4.11, then it 
is fine to commit now.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Tue, Jun 12, 2018 at 01:57:35AM -0600, Jan Beulich wrote:
> Let's focus on this scenario for now, as it is under better (timing) control
> on the Xen side. Below is a first debugging patch which
> - avoids the ASSERT() in question, instead triggering a printk(), in the hope
>   that the data logged and/or other ASSERT()s shed some additional light
>   on the situation
> - logs cleanup activity (this is likely to be quite chatty, so be sure you set
>   up large enough internal buffers)
> 
> Ideally, if no other ASSERT() triggers as a result of the bypassed one,
> you'd try to catch more than a single instance of the problem, so we can
> see a possible pattern (if there is one). A simplistic first XTF test I've
> created based on your description of the L2 handling model in NetBSD
> did not trigger the interesting printk(), but at least that way I've been
> able to see that the domain cleanup logging produces useful data.
> 
> At the very least I hope that with this we can derive whether the
> root of the problem is at page table teardown / cleanup time, or with
> management of live ones.

I applied this patch to 4.11rc4 (let's not change too much things at the
same time) and rebooted my test host. Hopefully I'll have some data to report
soon

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

[Xen-devel] [distros-debian-snapshot test] 74858: tolerable FAIL

[Platform Team regression test user]

flight 74858 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74858/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-daily-netboot-pvgrub 11 guest-start   fail like 74781
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74781
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
74781
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
74781
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
74781
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
74781
 test-amd64-amd64-amd64-daily-netboot-pvgrub 11 guest-start fail like 74781
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
74781
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 
74781
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 
74781
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
74781

baseline version:
 flight   74781

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


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

Re: [Xen-devel] [PATCH v1] unmodified_drivers: unplug the emulated devices at resume time

[Olaf Hering]

Am Tue, 12 Jun 2018 09:01:07 -0600
schrieb "Jan Beulich" :

> So there's no plan to fix this on the qemu side?

Even if there would be one, existing dom0s may not get an update in time.

I sent some prototype of a potential fix for qemu, it needs more work.


Olaf


pgpzDYSfvvGmr.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/1] libxl/xl: rename id to unique-id in vdispl xen store

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

In the display protocol connector's id is named as unique-id. This patch renames
it in the libxl/xl code and uses XENDISPL_FIELD... definitions from the protocol
header.

Signed-off-by: Oleksandr Grytsov 
---
 docs/man/xl.cfg.pod.5.in|  2 +-
 tools/libxl/libxl_types.idl |  4 ++--
 tools/libxl/libxl_vdispl.c  | 32 +---
 tools/xl/xl_parse.c |  2 +-
 tools/xl/xl_vdispl.c|  2 +-
 5 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 47d88243b1..ea66d867da 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1288,7 +1288,7 @@ Specifies virtual connectors for the device in following 
format
 
 =item C
 
-String connector ID. Space, comma symbols are not allowed.
+String connector unique id. Space, comma symbols are not allowed.
 
 =item C
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 01ec1d1afa..9a9d0ed52d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -809,7 +809,7 @@ libxl_device_channel = Struct("device_channel", [
 ])
 
 libxl_connector_param = Struct("connector_param", [
-("id", string),
+("unique_id", string),
 ("width", uint32),
 ("height", uint32)
 ])
@@ -935,7 +935,7 @@ libxl_physinfo = Struct("physinfo", [
 ], dir=DIR_OUT)
 
 libxl_connectorinfo = Struct("connectorinfo", [
-("id", string),
+("unique_id", string),
 ("width", uint32),
 ("height", uint32),
 ("req_evtch", integer),
diff --git a/tools/libxl/libxl_vdispl.c b/tools/libxl/libxl_vdispl.c
index 55dfac3e71..351f6beccb 100644
--- a/tools/libxl/libxl_vdispl.c
+++ b/tools/libxl/libxl_vdispl.c
@@ -14,6 +14,8 @@
 
 #include "libxl_internal.h"
 
+#include 
+
 static int libxl__device_vdispl_setdefault(libxl__gc *gc, uint32_t domid,
libxl_device_vdispl *vdispl,
bool hotplug)
@@ -66,15 +68,15 @@ static int libxl__set_xenstore_vdispl(libxl__gc *gc, 
uint32_t domid,
 {
 int i;
 
-flexarray_append_pair(ro_front, "be-alloc",
+flexarray_append_pair(ro_front, XENDISPL_FIELD_BE_ALLOC,
   GCSPRINTF("%d", vdispl->be_alloc));
 
 for (i = 0; i < vdispl->num_connectors; i++) {
-flexarray_append_pair(ro_front, GCSPRINTF("%d/resolution", i),
-  GCSPRINTF("%dx%d", vdispl->connectors[i].width,
+flexarray_append_pair(ro_front, 
GCSPRINTF("%d/"XENDISPL_FIELD_RESOLUTION, i),
+  GCSPRINTF("%d"XENDISPL_RESOLUTION_SEPARATOR"%d", 
vdispl->connectors[i].width,
  
vdispl->connectors[i].height));
-flexarray_append_pair(ro_front, GCSPRINTF("%d/id", i),
-  vdispl->connectors[i].id);
+flexarray_append_pair(ro_front, 
GCSPRINTF("%d/"XENDISPL_FIELD_UNIQUE_ID, i),
+  vdispl->connectors[i].unique_id);
 }
 
 return 0;
@@ -106,15 +108,15 @@ static int libxl__device_vdispl_getconnectors(libxl_ctx 
*ctx,
 char *value;
 char *value_path;
 
-value_path = GCSPRINTF("%s/%d/id", path, i);
-info->connectors[i].id = xs_read(ctx->xsh, XBT_NULL, value_path, NULL);
-if (info->connectors[i].id == NULL) { rc = ERROR_FAIL; goto out; }
+value_path = GCSPRINTF("%s/%d/"XENDISPL_FIELD_UNIQUE_ID, path, i);
+info->connectors[i].unique_id = xs_read(ctx->xsh, XBT_NULL, 
value_path, NULL);
+if (info->connectors[i].unique_id == NULL) { rc = ERROR_FAIL; goto 
out; }
 
-value_path = GCSPRINTF("%s/%d/resolution", path, i);
+value_path = GCSPRINTF("%s/%d/"XENDISPL_FIELD_RESOLUTION, path, i);
 value = xs_read(ctx->xsh, XBT_NULL, value_path, NULL);
 if (value == NULL) { rc = ERROR_FAIL; goto out; }
 
-rc = sscanf(value, "%ux%u", >connectors[i].width,
+rc = sscanf(value, "%u"XENDISPL_RESOLUTION_SEPARATOR"%u", 
>connectors[i].width,
 >connectors[i].height);
 free(value);
 
@@ -122,22 +124,22 @@ static int libxl__device_vdispl_getconnectors(libxl_ctx 
*ctx,
 rc = ERROR_FAIL; goto out;
 }
 
-value_path = GCSPRINTF("%s/%d/req-ring-ref", path, i);
+value_path = GCSPRINTF("%s/%d/"XENDISPL_FIELD_REQ_RING_REF, path, i);
 value = xs_read(ctx->xsh, XBT_NULL, value_path, NULL);
 info->connectors[i].req_rref = value ? strtoul(value, NULL, 10) : -1;
 free(value);
 
-value_path = GCSPRINTF("%s/%d/req-event-channel", path, i);
+value_path = GCSPRINTF("%s/%d/"XENDISPL_FIELD_REQ_CHANNEL, path, i);
 value = xs_read(ctx->xsh, XBT_NULL, value_path, NULL);
 info->connectors[i].req_evtch = value ? strtoul(value, NULL, 10) : -1;
 free(value);
 
-value_path = GCSPRINTF("%s/%d/evt-ring-ref", path, i);
+

Re: [Xen-devel] [PATCH v5 07/10] arm: add a tiny kconfig configuration

[Stefano Stabellini]

On Tue, 12 Jun 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 12/06/18 01:50, Stefano Stabellini wrote:
> > On Tue, 5 Jun 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 04/06/18 18:24, Stefano Stabellini wrote:
> > > > Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
> > > > Support only 8 cpus. It only carries non-default options (use make
> > > 
> > > I don't see where 8 CPUs would only be supported as the default value is
> > > 128
> > > cpus.
> >   I need to update the commit message reflecting the changes to the patch
> > 
> > 
> > > > olddefconfig to produce a complete .config file).
> > > 
> > > With all the series I did the following things:
> > >   1) copy tiny.config to .config
> > >   2) make olddefconfig
> > >   3) make menuconfig and select QEMU
> > > 
> > > After 1) the numbers of CPUs are set to 128. After 3) I would expect the
> > > number of CPUs to go down to 8. Unfortunately this is not the cases.
> > > 
> > > So your command does not seem to be enough here.
> > 
> > NR_CPUS cannot go down. It is a limitation of Kconfig, similar to the
> > fact that option cannot be de-selected.
> > 
> > It is not 1) that sets NR_CPUS to 128, it would be 2) above. For this to
> > work you have to skip 2) and just do:
> > 
> > - copy tiny.config to .config
> > - make menuconfig and select QEMU
> 
> Well I suggested a way during one of our recent chat and I am a bit surprised
> this was not considered here.
> 
> For reminder, the way was to provide a makefile target that will select tiny
> and the platform at the same time.
> 
> make tiny_defconfig PLAT=qemu

I prefer not to add additional targets

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Andrew Cooper]

On 12/06/18 16:38, Manuel Bouyer wrote:
> On Tue, Jun 12, 2018 at 01:39:05PM +0200, Manuel Bouyer wrote:
>> I applied this patch to 4.11rc4 (let's not change too much things at the
>> same time) and rebooted my test host. Hopefully I'll have some data to report
>> soon
> Got the first panic (still from a i386 domU):
> login: (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], 
> stk :8301bf117f78, dr6 0ff0
> (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> :8301bf117f78, dr6 0ff0
> (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> :8301bf117f78, dr6 0ff0
> (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> :8301bf117f78, dr6 0ff0
> (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> :8301bf117f78, dr6 0ff0
> (XEN) d4v2 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> :8301bf077f78, dr6 0ff0

I presume you're running a XSA-263 (MovSS) exploit in testing?

~Andrew

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

Re: [Xen-devel] [PATCH v1] unmodified_drivers: unplug the emulated devices at resume time

[Jan Beulich]

>>> On 12.06.18 at 16:10,  wrote:
> Since qemu-2.10 it is required to unplug emulated devices again after
> a live migration. If this is not done, qemu's block-backend driver
> will be unable to open the backing disk image because it is still busy
> by qemu's IDE driver. As a result the domUs block-frontend driver will
> be unable to access the disks, and the domU has to be destroyed.
> libxl is unable to detect the situation.

So there's no plan to fix this on the qemu side?

> Apply the same workaround for this qemu bug that was done already
> years ago in linux.git with commit 512b109ec962 ("xen: unplug the
> emulated devices at resume time") to make sure xenlinux based domUs
> can be migrated to unfixed hosts.

Hmm, that change has no explanation whatsoever of why this was
necessary already back at that time. Stefano?

Jan



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

Re: [Xen-devel] [PATCH] xen/altp2m: set access_required properly for all altp2ms

[Razvan Cojocaru]

On 06/12/2018 03:35 PM, Razvan Cojocaru wrote:
>>> @@ -210,7 +211,7 @@ static int p2m_init_altp2m(struct domain *d)
>>>  return -ENOMEM;
>>>  }
>>>  p2m->p2m_class = p2m_alternate;
>>> -p2m->access_required = 1;
>>> +p2m->access_required = hostp2m->access_required;
>> There must have been a reason to have it start out as 1. You
>> mention the fact in the description, but not why it is okay (or
>> even necessary) to change it.
> If there was one, I can't see what it was. It in any case make altp2ms
> behave differently than the hostp2m. The mem_access system has been
> designed so that the user can say "this domain should now no longer be
> able to continue if there are EPT violatios and there's no vm_event
> subscriber attached".
> 
> Our application, for one, explicitly _disables_ access_required - so
> that it is able to detach from the domain and reattach later. Hence the
> surprise when an altp2m-enabled domain crashed when the introspection
> agent detached.
> 
> Basically, the altp2m behaviour can't be controlled at all here. Maybe
> Tamas remembers / knows more about why access_required ended up being 1
> always, but it was probably just the quickest way to write the original
> patch.

CCd Tamas.

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

[Xen-devel] [xen-unstable test] 123379: regressions - FAIL

[Juergen Gross]

On 08/06/18 12:12, Juergen Gross wrote:
> On 07/06/18 13:30, Juergen Gross wrote:
>> On 06/06/18 11:40, Juergen Gross wrote:
>>> On 06/06/18 11:35, Jan Beulich wrote:
>>> On 05.06.18 at 18:19,  wrote:
>>>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 
>>> guest-saverestore.2 
>
> I thought I would reply again with the key point from my earlier mail
> highlighted, and go a bit further.  The first thing to go wrong in
> this was:
>
> 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14 = 
> Bad address): Internal error
> 2018-05-30 22:12:49.483+: xc: Save failed (14 = Bad address): 
> Internal error
> 2018-05-30 22:12:49.648+: libxl-save-helper: complete r=-1: Bad 
> address
>
> You can see similar messages in the other logfile:
>
> 2018-05-30 22:12:49.650+: libxl: 
> libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving 
> domain: domain responded to suspend request: Bad address
>
> All of these are reports of the same thing: xc_get_pfn_type_batch at
> xc_sr_save.c:133 failed with EFAULT.  I'm afraid I don't know why.
>
> There is no corresponding message in the host's serial log nor the
> dom0 kernel log.

 I vaguely recall from the time when I had looked at the similar Windows
 migration issues that the guest is already in the process of being cleaned
 up when these occur. Commit 2dbe9c3cd2 ("x86/mm: silence a pointless
 warning") intentionally suppressed a log message here, and the
 immediately following debugging code (933f966bcd x86/mm: add
 temporary debugging code to get_page_from_gfn_p2m()) was reverted
 a little over a month later. This wasn't as a follow-up to another patch
 (fix), but following the discussion rooted at
 https://lists.xenproject.org/archives/html/xen-devel/2017-06/msg00324.html
>>>
>>> That was -ESRCH, not -EFAULT.
>>
>> I've looked a little bit more into this.
>>
>> As we are seeing EFAULT being returned by the hypervisor this either
>> means the tools are specifying an invalid address (quite unlikely)
>> or the buffers are not as MAP_LOCKED as we wish them to be.
>>
>> Is there a way to see whether the host was experiencing some memory
>> shortage, so the buffers might have been swapped out?
>>
>> man mmap tells me: "This implementation will try to populate (prefault)
>> the whole range but the mmap call doesn't fail with ENOMEM if this
>> fails. Therefore major faults might happen later on."
>>
>> And: "One should use mmap(2) plus mlock(2) when major faults are not
>> acceptable after the initialization of the mapping."
>>
>> With osdep_alloc_pages() in tools/libs/call/linux.c touching all the
>> hypercall buffer pages before doing the hypercall I'm not sure this
>> could be an issue.
>>
>> Any thoughts on that?
> 
> Ian, is there a chance to dedicate a machine to a specific test trying
> to reproduce the problem? In case we manage to get this failure in a
> reasonable time frame I guess the most promising approach would be to
> use a test hypervisor producing more debug data. If you think this is
> worth doing I can write a patch.

Trying to reproduce the problem in a limited test environment finally
worked: doing a loop of "xl save -c" produced the problem after 198
iterations.

I have asked a SUSE engineer doing kernel memory management if he
could think of something. His idea is that maybe some kthread could be
the reason for our problem, e.g. trying page migration or compaction
(at least on the test machine I've looked at compaction of mlocked
pages is allowed: /proc/sys/vm/compact_unevictable_allowed is 1).

In order to be really sure nothing in the kernel can temporarily
switch hypercall buffer pages read-only or invalid for the hypervisor
we'll have to modify the privcmd driver interface: it will have to
gain knowledge which pages are handed over to the hypervisor as buffers
in order to be able to lock them accordingly via get_user_pages().

While this is a possible explanation of the fault we are seeing it might
be related to another reason. So I'm going to apply some modifications
to the hypervisor to get some more diagnostics in order to verify the
suspected kernel behavior is really the reason for the hypervisor to
return EFAULT.


Juergen

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Tue, Jun 12, 2018 at 04:54:30PM +0100, Andrew Cooper wrote:
> On 12/06/18 16:38, Manuel Bouyer wrote:
> > On Tue, Jun 12, 2018 at 01:39:05PM +0200, Manuel Bouyer wrote:
> >> I applied this patch to 4.11rc4 (let's not change too much things at the
> >> same time) and rebooted my test host. Hopefully I'll have some data to 
> >> report
> >> soon
> > Got the first panic (still from a i386 domU):
> > login: (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], 
> > stk :8301bf117f78, dr6 0ff0
> > (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> > :8301bf117f78, dr6 0ff0
> > (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> > :8301bf117f78, dr6 0ff0
> > (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> > :8301bf117f78, dr6 0ff0
> > (XEN) d4v0 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> > :8301bf117f78, dr6 0ff0
> > (XEN) d4v2 Hit #DB in Xen context: e008:82d08036eb00 [overflow], stk 
> > :8301bf077f78, dr6 0ff0
> 
> I presume you're running a XSA-263 (MovSS) exploit in testing?

Not intentionally, these are the NetBSD test suite and I don't think any
specifically targets this (there are 759 tests at this time).
But these includes network tests, so there is probably in kernel bpf code tests.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

Re: [Xen-devel] [PATCH v5 07/10] arm: add a tiny kconfig configuration

[Julien Grall]

Hi,

On 12/06/18 16:55, Stefano Stabellini wrote:

On Tue, 12 Jun 2018, Julien Grall wrote:

Hi Stefano,

On 12/06/18 01:50, Stefano Stabellini wrote:

On Tue, 5 Jun 2018, Julien Grall wrote:

Hi Stefano,

On 04/06/18 18:24, Stefano Stabellini wrote:

Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
Support only 8 cpus. It only carries non-default options (use make


I don't see where 8 CPUs would only be supported as the default value is
128
cpus.

   I need to update the commit message reflecting the changes to the patch



olddefconfig to produce a complete .config file).


With all the series I did the following things:
1) copy tiny.config to .config
2) make olddefconfig
3) make menuconfig and select QEMU

After 1) the numbers of CPUs are set to 128. After 3) I would expect the
number of CPUs to go down to 8. Unfortunately this is not the cases.

So your command does not seem to be enough here.


NR_CPUS cannot go down. It is a limitation of Kconfig, similar to the
fact that option cannot be de-selected.

It is not 1) that sets NR_CPUS to 128, it would be 2) above. For this to
work you have to skip 2) and just do:

- copy tiny.config to .config
- make menuconfig and select QEMU


Well I suggested a way during one of our recent chat and I am a bit surprised
this was not considered here.

For reminder, the way was to provide a makefile target that will select tiny
and the platform at the same time.

make tiny_defconfig PLAT=qemu


I prefer not to add additional targets


I think it would make easier for user to select any config and the 
platform. It is one command over 3 that can mistakenly be misused.


Anyway, sooner or later we will want to have such target in Xen.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 



diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h
new file mode 100644
index ..e0939387278d
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Xen memory reservation utilities.
+ *
+ * Copyright (c) 2003, B Dragovic
+ * Copyright (c) 2003-2004, M Williamson, K Fraser
+ * Copyright (c) 2005 Dan M. Smith, IBM Corporation
+ * Copyright (c) 2010 Daniel Kiper
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _XENMEM_RESERVATION_H
+#define _XENMEM_RESERVATION_H
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 



I should have noticed this in the previous post but I suspect most of 
these includes belong in the C file. For example, there is no reason for 
hypercall.h here.


-boris



+
+static inline void xenmem_reservation_scrub_page(struct page *page)
+{
+#ifdef CONFIG_XEN_SCRUB_PAGES
+   clear_highpage(page);
+#endif
+}
+
+#ifdef CONFIG_XEN_HAVE_PVMMU
+void __xenmem_reservation_va_mapping_update(unsigned long count,
+   struct page **pages,
+   xen_pfn_t *frames);
+
+void __xenmem_reservation_va_mapping_reset(unsigned long count,
+  struct page **pages);
+#endif
+
+static inline void xenmem_reservation_va_mapping_update(unsigned long count,
+   struct page **pages,
+   xen_pfn_t *frames)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+   if (!xen_feature(XENFEAT_auto_translated_physmap))
+   __xenmem_reservation_va_mapping_update(count, pages, frames);
+#endif
+}
+
+static inline void xenmem_reservation_va_mapping_reset(unsigned long count,
+  struct page **pages)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+   if (!xen_feature(XENFEAT_auto_translated_physmap))
+   __xenmem_reservation_va_mapping_reset(count, pages);
+#endif
+}
+
+int xenmem_reservation_increase(int count, xen_pfn_t *frames);
+
+int xenmem_reservation_decrease(int count, xen_pfn_t *frames);
+
+#endif



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

Re: [Xen-devel] [PATCH v3 4/9] xen/grant-table: Allow allocating buffers suitable for DMA

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is made
({increase|decrease}_reservation and VA mappings updated if needed).
This is useful for sharing foreign buffers with HW drivers which
cannot work with scattered buffers provided by the balloon driver,
but require DMAable memory instead.

Signed-off-by: Oleksandr Andrushchenko 


Reviewed-by: Boris Ostrovsky 

with a small nit below



---
  drivers/xen/Kconfig   | 13 ++
  drivers/xen/grant-table.c | 97 +++
  include/xen/grant_table.h | 18 
  3 files changed, 128 insertions(+)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e5d0c28372ea..39536ddfbce4 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -161,6 +161,19 @@ config XEN_GRANT_DEV_ALLOC
  to other domains. This can be used to implement frontend drivers
  or as part of an inter-domain shared memory channel.
  
+config XEN_GRANT_DMA_ALLOC

+   bool "Allow allocating DMA capable buffers with grant reference module"
+   depends on XEN && HAS_DMA
+   help
+ Extends grant table module API to allow allocating DMA capable
+ buffers and mapping foreign grant references on top of it.
+ The resulting buffer is similar to one allocated by the balloon
+ driver in terms that proper memory reservation is made
+ ({increase|decrease}_reservation and VA mappings updated if needed).


I think you should drop the word "terms" and say "is made *by*" and "VA 
mappings *are* updated"


And similar change in the commit message.

-boris


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

Re: [Xen-devel] [PATCH v3 5/9] xen/gntdev: Allow mappings for DMA buffers

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:

  
  static void gntdev_print_maps(struct gntdev_priv *priv,

@@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map)
if (map == NULL)
return;
  
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC

+   if (map->dma_vaddr) {
+   struct gnttab_dma_alloc_args args;
+
+   args.dev = map->dma_dev;
+   args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;



args.coherent = !!(map->dma_flags & GNTDEV_DMA_FLAG_COHERENT);



+   args.nr_pages = map->count;
+   args.pages = map->pages;
+   args.frames = map->frames;
+   args.vaddr = map->dma_vaddr;
+   args.dev_bus_addr = map->dma_bus_addr;
+
+   gnttab_dma_free_pages();
+   } else
+#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+   kfree(map->frames);
+#endif
kfree(map->pages);
kfree(map->grants);
kfree(map->map_ops);
@@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map *map)
kfree(map);
  }
  
-static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)

+static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count,
+ int dma_flags)
  {
struct grant_map *add;
int i;
@@ -155,6 +200,37 @@ static struct grant_map *gntdev_alloc_map(struct 
gntdev_priv *priv, int count)
NULL == add->pages)
goto err;
  
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC

+   add->dma_flags = dma_flags;
+
+   /*
+* Check if this mapping is requested to be backed
+* by a DMA buffer.
+*/
+   if (dma_flags & (GNTDEV_DMA_FLAG_WC | GNTDEV_DMA_FLAG_COHERENT)) {
+   struct gnttab_dma_alloc_args args;
+
+   add->frames = kcalloc(count, sizeof(add->frames[0]),
+ GFP_KERNEL);
+   if (!add->frames)
+   goto err;
+
+   /* Remember the device, so we can free DMA memory. */
+   add->dma_dev = priv->dma_dev;
+
+   args.dev = priv->dma_dev;
+   args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;



And again here.



+   args.nr_pages = count;
+   args.pages = add->pages;
+   args.frames = add->frames;
+
+   if (gnttab_dma_alloc_pages())
+   goto err;
+
+   add->dma_vaddr = args.vaddr;
+   add->dma_bus_addr = args.dev_bus_addr;
+   } else
+#endif
if (gnttab_alloc_pages(count, add->pages))
goto err;
  
@@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)

map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+   else if (map->dma_vaddr) {
+   unsigned long mfn;



This should be called bfn now.



+
+   mfn = pfn_to_bfn(page_to_pfn(map->pages[i]));
+   map->unmap_ops[i].dev_bus_addr = __pfn_to_phys(mfn);
+   }
+#endif
}
return err;
  }
@@ -548,6 +632,17 @@ static int gntdev_open(struct inode *inode, struct file 
*flip)
}
  
  	flip->private_data = priv;

+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+   priv->dma_dev = gntdev_miscdev.this_device;
+
+   /*
+* The device is not spawn from a device tree, so arch_setup_dma_ops
+* is not called, thus leaving the device with dummy DMA ops.
+* Fix this call of_dma_configure() with a NULL node to set



"Fix this by calling ..." I think.



+* default DMA ops.
+*/
+   of_dma_configure(priv->dma_dev, NULL);
+#endif
pr_debug("priv %p\n", priv);
  
  	return 0;



With those fixed,

Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen

[Dmitry Torokhov]

On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko 
> > 
> > This is the sync up with the canonical definitions of the input,
> > sound and display protocols in Xen.
> > 
> > Changes to kbdif:
> > 1. Add missing string constants for {feature|request}-raw-pointer
> >to align with the rest of the interface file.
> > 
> > 2. Add new XenStore feature fields, so it is possible to individually
> >control set of exposed virtual devices for each guest OS:
> >  - set feature-disable-keyboard to 1 if no keyboard device needs
> >to be created
> >  - set feature-disable-pointer to 1 if no pointer device needs
> >to be created
> > 
> > 3. Move multi-touch device parameters to backend nodes: these are
> > described as a part of frontend's XenBus configuration nodes
> > while they belong to backend's configuration. Fix this by moving
> > the parameters to the proper section.
> > 
> > Unique-id field:
> > 1. Add unique-id XenBus entry for virtual input and display.
> > 
> > 2. Change type of unique-id field to string for sndif to align with
> > display and input protocols.
> > 
> > Signed-off-by: Oleksandr Andrushchenko 
> > Cc: Konrad Rzeszutek Wilk 
> 
> Reviewed-by: Juergen Gross 
> 
> I'm fine with this patch being added via the input tree with the other
> patches. In case I should take it via the Xen tree, please send me a
> note.

Juergen,

I created an immutable branch off v4.17 with these 3 patches in case you
would want to merge them into your tree without waiting for them to
appear in mainline:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git 
ib/4.17-xen-kbdfront-runtime-config

Thanks.

-- 
Dmitry

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

Re: [Xen-devel] [PATCH v3 6/9] xen/gntdev: Make private routines/structures accessible

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev now.

Signed-off-by: Oleksandr Andrushchenko 
---
  drivers/xen/gntdev-common.h |  86 +++
  drivers/xen/gntdev.c| 132 
  2 files changed, 128 insertions(+), 90 deletions(-)
  create mode 100644 drivers/xen/gntdev-common.h

diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
new file mode 100644
index ..7a9845a6bee9
--- /dev/null
+++ b/drivers/xen/gntdev-common.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Common functionality of grant device.
+ *
+ * Copyright (c) 2006-2007, D G Murray.
+ *   (c) 2009 Gerd Hoffmann 
+ *   (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _GNTDEV_COMMON_H
+#define _GNTDEV_COMMON_H
+
+#include 
+#include 
+#include 
+#include 
+
+struct gntdev_priv {
+   /* maps with visible offsets in the file descriptor */
+   struct list_head maps;
+   /* maps that are not visible; will be freed on munmap.
+* Only populated if populate_freeable_maps == 1 */



Since you are touching this code please fix comment style.



+   struct list_head freeable_maps;
+   /* lock protects maps and freeable_maps */
+   struct mutex lock;
+   struct mm_struct *mm;
+   struct mmu_notifier mn;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+   /* Device for which DMA memory is allocated. */
+   struct device *dma_dev;
+#endif
+};



With that fixed,

Reviewed-by: Boris Ostrovsky 


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

[Xen-devel] [xen-4.8-testing test] 124100: regressions - FAIL

[osstest service owner]

flight 124100 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124100/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm  broken  in 124070
 build-i386-pvops  6 kernel-build   fail in 123844 REGR. vs. 123091
 build-armhf   6 xen-build  fail in 123844 REGR. vs. 123091
 build-armhf-xsm  5 host-build-prep fail in 124070 REGR. vs. 123091

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-credit2   7 xen-boot fail in 123701 pass in 124100
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail in 123701 pass 
in 124100
 test-amd64-amd64-livepatch7 xen-boot fail in 123701 pass in 124100
 test-amd64-amd64-pair   10 xen-boot/src_host fail in 123701 pass in 124100
 test-amd64-amd64-pair   11 xen-boot/dst_host fail in 123701 pass in 124100
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail in 123701 pass in 124100
 test-amd64-i386-rumprun-i386  7 xen-boot fail in 123701 pass in 124100
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail in 123701 pass in 
124100
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail in 123701 pass in 124100
 test-amd64-i386-libvirt-xsm   7 xen-boot fail in 123701 pass in 124100
 test-amd64-i386-migrupgrade 10 xen-boot/src_host fail in 123701 pass in 124100
 test-amd64-i386-migrupgrade 11 xen-boot/dst_host fail in 123701 pass in 124100
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail in 123701 pass in 124100
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail in 123701 pass in 124100
 test-xtf-amd64-amd64-37 xen-boot fail in 123844 pass in 124100
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
123701
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 123844
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
124070
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 13 guest-saverestore fail pass 
in 124070

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 
123844 n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
123844 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 123844 n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 123844 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1) blocked in 123844 n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
123844 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  blocked in 123844 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)blocked in 123844 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked in 123844 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 123844 n/a
 build-armhf-libvirt   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-pair  1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked in 123844 n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)blocked in 123844 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 

Re: [Xen-devel] [PATCH v3 7/9] xen/gntdev: Add initial support for dma-buf UAPI

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:


diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a09db23e9663..e82660d81d7e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -48,6 +48,9 @@
  #include 
  
  #include "gntdev-common.h"

+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+#include "gntdev-dmabuf.h"
+#endif
  
  MODULE_LICENSE("GPL");

  MODULE_AUTHOR("Derek G. Murray , "
@@ -566,6 +569,15 @@ static int gntdev_open(struct inode *inode, struct file 
*flip)
INIT_LIST_HEAD(>freeable_maps);
mutex_init(>lock);
  
+#ifdef CONFIG_XEN_GNTDEV_DMABUF

+   priv->dmabuf_priv = gntdev_dmabuf_init();
+   if (IS_ERR(priv->dmabuf_priv)) {
+   ret = PTR_ERR(priv->dmabuf_priv);
+   kfree(priv);
+   return ret;
+   }
+#endif
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -616,8 +628,13 @@ static int gntdev_release(struct inode *inode, struct file 
*flip)
WARN_ON(!list_empty(>freeable_maps));
mutex_unlock(>lock);
  
+#ifdef CONFIG_XEN_GNTDEV_DMABUF

+   gntdev_dmabuf_fini(priv->dmabuf_priv);
+#endif
+
if (use_ptemod)
mmu_notifier_unregister(>mn, priv->mm);
+
kfree(priv);
return 0;
  }
@@ -987,6 +1004,107 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv 
*priv, void __user *u)
return ret;
  }
  
+#ifdef CONFIG_XEN_GNTDEV_DMABUF

+static long
+gntdev_ioctl_dmabuf_exp_from_refs(struct gntdev_priv *priv,
+ struct ioctl_gntdev_dmabuf_exp_from_refs 
__user *u)



Didn't we agree that this code moves to gntdev-dmabuf.c ?

-boris


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

Re: [Xen-devel] [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.

2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file descriptor
does not exist or has already been released, then -ENOENT is
returned. For valid file descriptors this must not be treated as
error.

3. Make gntdev's common code and structures available to dma-buf.

Signed-off-by: Oleksandr Andrushchenko 
---
  drivers/xen/gntdev-common.h |   4 +
  drivers/xen/gntdev-dmabuf.c | 470 +++-
  drivers/xen/gntdev.c|  10 +
  3 files changed, 482 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index a3408fd39b07..72f80dbce861 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -89,4 +89,8 @@ bool gntdev_account_mapped_pages(int count);
  
  int gntdev_map_grant_pages(struct gntdev_grant_map *map);
  
+#ifdef CONFIG_XEN_GNTDEV_DMABUF

+void gntdev_remove_map(struct gntdev_priv *priv, struct gntdev_grant_map *map);
+#endif
+
  #endif
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index dc57c6a25525..84cba67c6ad7 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -3,13 +3,53 @@
  /*
   * Xen dma-buf functionality for gntdev.
   *
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
   * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
   */
  
+#include 

  #include 
  
+#include 

+#include 
+
+#include "gntdev-common.h"
  #include "gntdev-dmabuf.h"
  
+struct gntdev_dmabuf {

+   struct gntdev_dmabuf_priv *priv;
+   struct dma_buf *dmabuf;
+   struct list_head next;
+   int fd;
+
+   union {
+   struct {
+   /* Exported buffers are reference counted. */
+   struct kref refcount;
+
+   struct gntdev_priv *priv;
+   struct gntdev_grant_map *map;
+   } exp;
+   } u;
+
+   /* Number of pages this buffer has. */
+   int nr_pages;
+   /* Pages of this buffer. */
+   struct page **pages;
+};
+
+struct gntdev_dmabuf_wait_obj {
+   struct list_head next;
+   struct gntdev_dmabuf *gntdev_dmabuf;
+   struct completion completion;
+};
+
+struct gntdev_dmabuf_attachment {
+   struct sg_table *sgt;
+   enum dma_data_direction dir;
+};
+
  struct gntdev_dmabuf_priv {
/* List of exported DMA buffers. */
struct list_head exp_list;
@@ -23,17 +63,439 @@ struct gntdev_dmabuf_priv {
  
  /* Implementation of wait for exported DMA buffer to be released. */
  
+static void dmabuf_exp_release(struct kref *kref);

+
+static struct gntdev_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv,
+   struct gntdev_dmabuf *gntdev_dmabuf)
+{
+   struct gntdev_dmabuf_wait_obj *obj;
+
+   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+   if (!obj)
+   return ERR_PTR(-ENOMEM);
+
+   init_completion(>completion);
+   obj->gntdev_dmabuf = gntdev_dmabuf;
+
+   mutex_lock(>lock);
+   list_add(>next, >exp_wait_list);
+   /* Put our reference and wait for gntdev_dmabuf's release to fire. */
+   kref_put(_dmabuf->u.exp.refcount, dmabuf_exp_release);
+   mutex_unlock(>lock);
+   return obj;
+}
+
+static void dmabuf_exp_wait_obj_free(struct gntdev_dmabuf_priv *priv,
+struct gntdev_dmabuf_wait_obj *obj)
+{
+   struct gntdev_dmabuf_wait_obj *cur_obj, *q;
+
+   mutex_lock(>lock);
+   list_for_each_entry_safe(cur_obj, q, >exp_wait_list, next)
+   if (cur_obj == obj) {
+   list_del(>next);
+   kfree(obj);
+   break;
+   }
+   mutex_unlock(>lock);



Do we really need to walk the list?

And if we do, do we need the safe variant of the walk? We are holding 
the lock. Here and elsewhere.




+}
+
+static int dmabuf_exp_wait_obj_wait(struct gntdev_dmabuf_wait_obj *obj,
+   u32 wait_to_ms)
+{
+   if (wait_for_completion_timeout(>completion,
+   msecs_to_jiffies(wait_to_ms)) <= 0)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+static void dmabuf_exp_wait_obj_signal(struct gntdev_dmabuf_priv *priv,
+  struct 

Re: [Xen-devel] [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

[Boris Ostrovsky]

On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:


  int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
  {
-   return -EINVAL;
+   struct gntdev_dmabuf *gntdev_dmabuf;
+   struct dma_buf_attachment *attach;
+   struct dma_buf *dma_buf;
+
+   gntdev_dmabuf = dmabuf_imp_find_unlink(priv, fd);
+   if (IS_ERR(gntdev_dmabuf))
+   return PTR_ERR(gntdev_dmabuf);
+
+   pr_debug("Releasing DMA buffer with fd %d\n", fd);
+
+   attach = gntdev_dmabuf->u.imp.attach;
+
+   if (gntdev_dmabuf->u.imp.sgt)
+   dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
+DMA_BIDIRECTIONAL);
+   dma_buf = attach->dmabuf;
+   dma_buf_detach(attach->dmabuf, attach);
+   dma_buf_put(dma_buf);
+
+   dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs,
+ gntdev_dmabuf->nr_pages);




Should you first end foreign access, before doing anything?

-boris



+   dmabuf_imp_free_storage(gntdev_dmabuf);
+   return 0;
  }
  


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

Re: [Xen-devel] [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

[Boris Ostrovsky]

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:



One more thing: please add a comment here saying that frames array is 
array of PFNs (in Xen granularity), which is what 
XENMEM_populate_physmap requires. And remove (or update to name the 
actual call you are making) the corresponding comment in 
increase_reservation().




+
+int xenmem_reservation_increase(int count, xen_pfn_t *frames)
+{
+   struct xen_memory_reservation reservation = {
+   .address_bits = 0,
+   .extent_order = EXTENT_ORDER,
+   .domid= DOMID_SELF
+   };
+
+   set_xen_guest_handle(reservation.extent_start, frames);
+   reservation.nr_extents = count;
+   return HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+}
+EXPORT_SYMBOL_GPL(xenmem_reservation_increase);



And similarly, here we are requesting GFNs, and update 
decrease_reservation().



-boris


+
+int xenmem_reservation_decrease(int count, xen_pfn_t *frames)
+{
+   struct xen_memory_reservation reservation = {
+   .address_bits = 0,
+   .extent_order = EXTENT_ORDER,
+   .domid= DOMID_SELF
+   };
+
+   set_xen_guest_handle(reservation.extent_start, frames);
+   reservation.nr_extents = count;
+   return HYPERVISOR_memory_op(XENMEM_decrease_reservation, );


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

[Xen-devel] strange behavior with Multiboot2 on EFI

[Kristaps Čivkulis]

Hello,

I am implementing Multiboot2 support for FreeBSD loader to load Xen
kernel. Currently I pass EFI 64-bit system table pointer tag, EFI boot
services not terminated tag, EFI 64-bit image handle pointer tag and
Image load base physical address tag.

The problem is, Xen kernel gets stuck into infinite loop at address
near 0x7fa419be without printing anything. System table is at
0x7fbee018 and image handle is at 0x7f22fd98. If I debugged correctly,
it got into infinite loop after first time calling void
efi_console_set_mode(void) [0] because it didn't return from it.

Note that if I don't pass EFI 64-bit system table pointer tag, boot
services not terminated tag or 64-bit image handle pointer tag then
Xen kernel correctly prints error message!

Is this behavior intended? If not, where could be a problem?

I compiled Xen kernel on FreeBSD with this command:

# gmake -j4 xen clang=y LD=/usr/local/bin/ld CC="cc -B/usr/local/bin" \
  NM=/usr/local/bin/nm

and I test with this command:

$ qemu-system-x86_64 -m 2048 -bios OVMF-pure-efi.fd -hda test_disk.img

OVMF-pure-efi.fd is taken from
edk2.git-ovmf-x64-0-20180612.155.g5a56c04939.noarch.rpm at [1]

I also tried to load Xen kernel bare-metal with Grub2. I added
following lines to /boot/grub/grub.cfg:

menuentry 'xen' {
set root='hd0,gpt1'
multiboot2 /xen
}

and after launching Xen it also didn't print anything.


Thanks, Kristaps.

[0] 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/efi/boot.c;h=64d12685d35747d3734c1ad8ac27634e83bcf7db;hb=HEAD#l697
[1] https://www.kraxel.org/repos/jenkins/edk2/

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

Re: [Xen-devel] [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen

[Oleksandr Andrushchenko]

On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:

On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:

On 12/06/18 09:48, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This is the sync up with the canonical definitions of the input,
sound and display protocols in Xen.

Changes to kbdif:
1. Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.

2. Add new XenStore feature fields, so it is possible to individually
control set of exposed virtual devices for each guest OS:
  - set feature-disable-keyboard to 1 if no keyboard device needs
to be created
  - set feature-disable-pointer to 1 if no pointer device needs
to be created

3. Move multi-touch device parameters to backend nodes: these are
 described as a part of frontend's XenBus configuration nodes
 while they belong to backend's configuration. Fix this by moving
 the parameters to the proper section.

Unique-id field:
1. Add unique-id XenBus entry for virtual input and display.

2. Change type of unique-id field to string for sndif to align with
display and input protocols.

Signed-off-by: Oleksandr Andrushchenko 
Cc: Konrad Rzeszutek Wilk 

Reviewed-by: Juergen Gross 

I'm fine with this patch being added via the input tree with the other
patches. In case I should take it via the Xen tree, please send me a
note.

Juergen,

I created an immutable branch off v4.17 with these 3 patches in case you
would want to merge them into your tree without waiting for them to
appear in mainline:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git 
ib/4.17-xen-kbdfront-runtime-config

Thanks.


Thank you,
I would prefer the fastest path of course

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

Re: [Xen-devel] [PATCH v5 3/3] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

On 06/13/2018 01:07 AM, Dmitry Torokhov wrote:

On Tue, Jun 12, 2018 at 10:48:56AM +0300, Oleksandr Andrushchenko wrote:
  
+	if (!(with_kbd | with_ptr | with_mtouch)) {

I changed this to logical "OR" and applied, thank you.

Yes, that's better, thank you

+   ret = -ENXIO;
+   goto error;
+   }
+
ret = xenkbd_connect_backend(dev, info);
if (ret < 0)
goto error;
--
2.17.1




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

Re: [Xen-devel] [Qemu-devel] [PATCH v4 11/40] hw/xen: Use the IEC binary prefix definitions

[Richard Henderson]

On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote:
>  xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename 
> \"%s\","
> -  " size %" PRId64 " (%" PRId64 " MB)\n",
> +  " size %" PRId64 " (%llu MB)\n",
>blkdev->type, blkdev->fileproto, blkdev->filename,
> -  blkdev->file_size, blkdev->file_size >> 20);
> +  blkdev->file_size, blkdev->file_size / MiB);

Having to change printf markup is exactly why you shouldn't use ULL in MiB.


r~

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

[Xen-devel] [RFC PATCH 03/12] xenbus: add freeze/thaw/restore callbacks support

[Anchal Agarwal]

From: Munehisa Kamata 

Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
respectively, and only suspend and resume callbacks are supported at
driver level. To support PM suspend and PM hibernation, modify the bus
level PM callbacks to invoke not only device driver's suspend/resume but
also freeze/thaw/restore.

Note that we'll use freeze/restore callbacks even for PM suspend whereas
suspend/resume callbacks are normally used in the case, becausae the
existing xenbus device drivers already have suspend/resume callbacks
specifically designed for Xen suspend. So we can allow the device
drivers to keep the existing callbacks wihtout modification.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 drivers/xen/xenbus/xenbus_probe.c | 102 --
 include/xen/xenbus.h  |   3 ++
 2 files changed, 89 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index ec9eb4f..95b0a6d 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -588,26 +589,47 @@ int xenbus_dev_suspend(struct device *dev)
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
+   int (*cb)(struct xenbus_device *) = NULL;
+   bool xen_suspend = xen_suspend_mode_is_xen_suspend();
 
DPRINTK("%s", xdev->nodename);
 
if (dev->driver == NULL)
return 0;
drv = to_xenbus_driver(dev->driver);
-   if (drv->suspend)
-   err = drv->suspend(xdev);
-   if (err)
-   pr_warn("suspend %s failed: %i\n", dev_name(dev), err);
+
+   if (xen_suspend)
+   cb = drv->suspend;
+   else
+   cb = drv->freeze;
+
+   if (cb)
+   err = cb(xdev);
+
+   if (err) {
+   pr_warn("%s %s failed: %i\n", xen_suspend ?
+   "suspend" : "freeze", dev_name(dev), err);
+   return err;
+   }
+
+   if (!xen_suspend) {
+   /* Forget otherend since this can become stale after restore */
+   free_otherend_watch(xdev);
+   free_otherend_details(xdev);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(xenbus_dev_suspend);
 
 int xenbus_dev_resume(struct device *dev)
 {
-   int err;
+   int err = 0;
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
+   int (*cb)(struct xenbus_device *) = NULL;
+   bool xen_suspend = xen_suspend_mode_is_xen_suspend();
 
DPRINTK("%s", xdev->nodename);
 
@@ -616,24 +638,34 @@ int xenbus_dev_resume(struct device *dev)
drv = to_xenbus_driver(dev->driver);
err = talk_to_otherend(xdev);
if (err) {
-   pr_warn("resume (talk_to_otherend) %s failed: %i\n",
+   pr_warn("%s (talk_to_otherend) %s failed: %i\n",
+   xen_suspend ? "resume" : "restore",
dev_name(dev), err);
return err;
}
 
-   xdev->state = XenbusStateInitialising;
+   if (xen_suspend)
+   xdev->state = XenbusStateInitialising;
 
-   if (drv->resume) {
-   err = drv->resume(xdev);
-   if (err) {
-   pr_warn("resume %s failed: %i\n", dev_name(dev), err);
-   return err;
-   }
+   if (xen_suspend)
+   cb = drv->resume;
+   else
+   cb = drv->restore;
+
+   if (cb)
+   err = cb(xdev);
+
+   if (err) {
+   pr_warn("%s %s failed: %i\n",
+   xen_suspend ? "resume" : "restore",
+   dev_name(dev), err);
+   return err;
}
 
err = watch_otherend(xdev);
if (err) {
-   pr_warn("resume (watch_otherend) %s failed: %d.\n",
+   pr_warn("%s (watch_otherend) %s failed: %d.\n",
+   xen_suspend ? "resume" : "restore",
dev_name(dev), err);
return err;
}
@@ -644,8 +676,46 @@ EXPORT_SYMBOL_GPL(xenbus_dev_resume);
 
 int xenbus_dev_cancel(struct device *dev)
 {
-   /* Do nothing */
-   DPRINTK("cancel");
+   int err = 0;
+   struct xenbus_driver *drv;
+   struct xenbus_device *xdev
+   = container_of(dev, struct xenbus_device, dev);
+   bool xen_suspend = xen_suspend_mode_is_xen_suspend();
+
+   if (xen_suspend) {
+   /* Do 

[Xen-devel] [RFC PATCH 05/12] x86/xen: add system core suspend and resume callbacks

[Anchal Agarwal]

From: Munehisa Kamata 

Add Xen PVHVM specific system core callbacks for PM suspend and
hibernation support. The callbacks suspend and resume Xen primitives,
like shared_info, pvclock and grant table. Note that Xen suspend can
handle them in a different manner, but system core callbacks are called
from the context. So if the callbacks are called from Xen suspend
context, return immediately.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 arch/x86/xen/enlighten_hvm.c |  1 +
 arch/x86/xen/suspend.c   | 53 
 include/xen/xen-ops.h|  2 ++
 3 files changed, 56 insertions(+)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index d24ad16..4196a65 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -202,6 +202,7 @@ static void __init xen_hvm_guest_init(void)
if (xen_feature(XENFEAT_hvm_callback_vector))
xen_have_vector_callback = 1;
 
+   xen_setup_syscore_ops();
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
xen_unplug_emulated_devices();
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 1d83152..784c448 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -2,17 +2,22 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "xen-ops.h"
 #include "mmu.h"
@@ -82,3 +87,51 @@ void xen_arch_suspend(void)
 
on_each_cpu(xen_vcpu_notify_suspend, NULL, 1);
 }
+
+static int xen_syscore_suspend(void)
+{
+   struct xen_remove_from_physmap xrfp;
+   int ret;
+
+   /* Xen suspend does similar stuffs in its own logic */
+   if (xen_suspend_mode_is_xen_suspend())
+   return 0;
+
+   xrfp.domid = DOMID_SELF;
+   xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
+
+   ret = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, );
+   if (!ret)
+   HYPERVISOR_shared_info = _dummy_shared_info;
+
+   return ret;
+}
+
+static void xen_syscore_resume(void)
+{
+   /* Xen suspend does similar stuffs in its own logic */
+   if (xen_suspend_mode_is_xen_suspend())
+   return;
+
+   /* No need to setup vcpu_info as it's already moved off */
+   xen_hvm_map_shared_info();
+
+   pvclock_resume();
+
+   gnttab_resume();
+}
+
+/*
+ * These callbacks will be called with interrupts disabled and when having only
+ * one CPU online.
+ */
+static struct syscore_ops xen_hvm_syscore_ops = {
+   .suspend = xen_syscore_suspend,
+   .resume = xen_syscore_resume
+};
+
+void __init xen_setup_syscore_ops(void)
+{
+   if (xen_hvm_domain())
+   register_syscore_ops(_hvm_syscore_ops);
+}
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index be78f6f..65f25bd 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -43,6 +43,8 @@ bool xen_suspend_mode_is_xen_suspend(void);
 bool xen_suspend_mode_is_pm_suspend(void);
 bool xen_suspend_mode_is_pm_hibernation(void);
 
+void xen_setup_syscore_ops(void);
+
 extern unsigned long *xen_contiguous_bitmap;
 
 #ifdef CONFIG_XEN_PV
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 02/12] xen/manage: introduce helper function to know the on-going suspend mode

[Anchal Agarwal]

From: Munehisa Kamata 

Introduce simple functions which help to know the on-going suspend mode
so that other Xen-related code can behave differently according to the
current suspend mode.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Alakesh Haloi 
Reviewed-by: Sebastian Biemueller 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 drivers/xen/manage.c  | 15 +++
 include/xen/xen-ops.h |  4 
 2 files changed, 19 insertions(+)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 8f9ea87..326631d 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -50,6 +50,21 @@ enum suspend_modes {
 /* Protected by pm_mutex */
 static enum suspend_modes suspend_mode = NO_SUSPEND;
 
+bool xen_suspend_mode_is_xen_suspend(void)
+{
+   return suspend_mode == XEN_SUSPEND;
+}
+
+bool xen_suspend_mode_is_pm_suspend(void)
+{
+   return suspend_mode == PM_SUSPEND;
+}
+
+bool xen_suspend_mode_is_pm_hibernation(void)
+{
+   return suspend_mode == PM_HIBERNATION;
+}
+
 struct suspend_info {
int cancelled;
 };
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index fd23e42..be78f6f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -39,6 +39,10 @@ u64 xen_steal_clock(int cpu);
 
 int xen_setup_shutdown_event(void);
 
+bool xen_suspend_mode_is_xen_suspend(void);
+bool xen_suspend_mode_is_pm_suspend(void);
+bool xen_suspend_mode_is_pm_hibernation(void);
+
 extern unsigned long *xen_contiguous_bitmap;
 
 #ifdef CONFIG_XEN_PV
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 01/12] xen/manage: keep track of the on-going suspend mode

[Anchal Agarwal]

From: Munehisa Kamata 

To differentiate between Xen suspend, PM suspend and PM hibernation,
keep track of the on-going suspend mode by mainly using a new PM
notifier. Since Xen suspend doesn't have corresponding PM event, its
main logic is modfied to acquire pm_mutex and set the current mode.

Note that we may see deadlock if PM suspend/hibernation is interrupted
by Xen suspend. PM suspend/hibernation depends on xenwatch thread to
process xenbus state transactions, but the thread will sleep to wait
pm_mutex which is already held by PM suspend/hibernation context in the
scenario. Though, acquirng pm_mutex is still right thing to do, and we
would need to modify Xen shutdown code to avoid the issue. This will be
fixed by a separate patch.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Sebastian Biemueller 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 drivers/xen/manage.c | 58 
 1 file changed, 58 insertions(+)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 8835065..8f9ea87 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -39,6 +40,16 @@ enum shutdown_state {
 /* Ignore multiple shutdown requests. */
 static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
 
+enum suspend_modes {
+   NO_SUSPEND = 0,
+   XEN_SUSPEND,
+   PM_SUSPEND,
+   PM_HIBERNATION,
+};
+
+/* Protected by pm_mutex */
+static enum suspend_modes suspend_mode = NO_SUSPEND;
+
 struct suspend_info {
int cancelled;
 };
@@ -98,6 +109,10 @@ static void do_suspend(void)
int err;
struct suspend_info si;
 
+   lock_system_sleep();
+
+   suspend_mode = XEN_SUSPEND;
+
shutting_down = SHUTDOWN_SUSPEND;
 
err = freeze_processes();
@@ -161,6 +176,10 @@ static void do_suspend(void)
thaw_processes();
 out:
shutting_down = SHUTDOWN_INVALID;
+
+   suspend_mode = NO_SUSPEND;
+
+   unlock_system_sleep();
 }
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
@@ -372,3 +391,42 @@ int xen_setup_shutdown_event(void)
 EXPORT_SYMBOL_GPL(xen_setup_shutdown_event);
 
 subsys_initcall(xen_setup_shutdown_event);
+
+static int xen_pm_notifier(struct notifier_block *notifier,
+  unsigned long pm_event, void *unused)
+{
+   switch (pm_event) {
+   case PM_SUSPEND_PREPARE:
+   suspend_mode = PM_SUSPEND;
+   break;
+   case PM_HIBERNATION_PREPARE:
+   case PM_RESTORE_PREPARE:
+   suspend_mode = PM_HIBERNATION;
+   break;
+   case PM_POST_SUSPEND:
+   case PM_POST_RESTORE:
+   case PM_POST_HIBERNATION:
+   /* Set back to the default */
+   suspend_mode = NO_SUSPEND;
+   break;
+   default:
+   pr_warn("Receive unknown PM event 0x%lx\n", pm_event);
+   return -EINVAL;
+   }
+
+   return 0;
+};
+
+static struct notifier_block xen_pm_notifier_block = {
+   .notifier_call = xen_pm_notifier
+};
+
+static int xen_setup_pm_notifier(void)
+{
+   if (!xen_hvm_domain())
+   return -ENODEV;
+
+   return register_pm_notifier(_pm_notifier_block);
+}
+
+subsys_initcall(xen_setup_pm_notifier);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 09/12] x86/xen: save and restore steal clock

[Anchal Agarwal]

From: Munehisa Kamata 

Save steal clock values of all present CPUs in the system core ops
suspend callbacks. Also, restore a boot CPU's steal clock in the system
core resume callback. For non-boot CPUs, restore after they're brought
up, because runstate info for non-boot CPUs are not active until then.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 arch/x86/xen/suspend.c | 13 -
 arch/x86/xen/time.c|  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 784c448..dae0f74 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -91,12 +91,20 @@ void xen_arch_suspend(void)
 static int xen_syscore_suspend(void)
 {
struct xen_remove_from_physmap xrfp;
-   int ret;
+   int cpu, ret;
 
/* Xen suspend does similar stuffs in its own logic */
if (xen_suspend_mode_is_xen_suspend())
return 0;
 
+   for_each_present_cpu(cpu) {
+   /*
+* Nonboot CPUs are already offline, but the last copy of
+* runstate info is still accessible.
+*/
+   xen_save_steal_clock(cpu);
+   }
+
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
 
@@ -118,6 +126,9 @@ static void xen_syscore_resume(void)
 
pvclock_resume();
 
+   /* Nonboot CPUs will be resumed when they're brought up */
+   xen_restore_steal_clock(smp_processor_id());
+
gnttab_resume();
 }
 
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index e0f1bcf..85f8534 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -523,6 +523,9 @@ static void xen_hvm_setup_cpu_clockevents(void)
 {
int cpu = smp_processor_id();
xen_setup_runstate_info(cpu);
+   if (cpu)
+   xen_restore_steal_clock(cpu);
+
/*
 * xen_setup_timer(cpu) - snprintf is bad in atomic context. Hence
 * doing it xen_hvm_cpu_notify (which gets called by smp_init during
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation

[Anchal Agarwal]

From: Munehisa Kamata 

Add freeze and restore callbacks for PM suspend and hibernation support.
The freeze handler stops a block-layer queue and disconnect the frontend
from the backend while freeing ring_info and associated resources. The
restore handler re-allocates ring_info and re-connect to the backedend,
so the rest of the kernel can continue to use the block device
transparently.Also, the handlers are used for both PM
suspend and hibernation so that we can keep the existing suspend/resume
callbacks for Xen suspend without modification.
If a backend doesn't have commit 12ea729645ac ("xen/blkback: unmap all
persistent grants when frontend gets disconnected"), the frontend may see
massive amount of grant table warning when freeing resources.

 [   36.852659] deferring g.e. 0xf9 (pfn 0x)
 [   36.855089] xen:grant_table: WARNING: g.e. 0x112 still in use!

In this case, persistent grants would need to be disabled.

Ensure no reqs/rsps in rings before disconnecting. When disconnecting
the frontend from the backend in blkfront_freeze(), there still may be
unconsumed requests or responses in the rings, especially when the
backend is backed by network-based device. If the frontend gets
disconnected with such reqs/rsps remaining there, it can cause
grant warnings and/or losing reqs/rsps by freeing pages afterward.
This can lead resumed kernel into unrecoverable state like unexpected
freeing of grant page and/or hung task due to the lost reqs or rsps.
Therefore we have to ensure that there is no unconsumed requests or
responses before disconnecting.

Actually, the frontend just needs to wait for some amount of time so that
the backend can process the requests, put responses and notify the
frontend back. Timeout used here is based on some heuristic. If we somehow
hit the timeout, it would mean something serious happens in the backend,
the frontend will just return an error to PM core and PM
suspend/hibernation will be aborted. This may be something should be
fixed by the backend side, but a frontend side fix is probably
still worth doing to work with broader backends.

Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 drivers/block/xen-blkfront.c | 158 +--
 1 file changed, 151 insertions(+), 7 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index ae00a82f350b..a223864c2220 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -46,6 +46,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -78,6 +80,8 @@ enum blkif_state {
BLKIF_STATE_DISCONNECTED,
BLKIF_STATE_CONNECTED,
BLKIF_STATE_SUSPENDED,
+   BLKIF_STATE_FREEZING,
+   BLKIF_STATE_FROZEN
 };
 
 struct grant {
@@ -216,6 +220,7 @@ struct blkfront_info
/* Save uncomplete reqs and bios for migration. */
struct list_head requests;
struct bio_list bio_list;
+   struct completion wait_backend_disconnected;
 };
 
 static unsigned int nr_minors;
@@ -262,6 +267,16 @@ static DEFINE_SPINLOCK(minor_lock);
 static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
 static void blkfront_gather_backend_features(struct blkfront_info *info);
 static int negotiate_mq(struct blkfront_info *info);
+static void __blkif_free(struct blkfront_info *info);
+
+static inline bool blkfront_ring_is_busy(struct blkif_front_ring *ring)
+{
+   if (RING_SIZE(ring) > RING_FREE_REQUESTS(ring) ||
+   RING_HAS_UNCONSUMED_RESPONSES(ring))
+   return true;
+   else
+   return false;
+}
 
 static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
 {
@@ -996,6 +1011,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 
sector_size,
info->sector_size = sector_size;
info->physical_sector_size = physical_sector_size;
blkif_set_queue_limits(info);
+   init_completion(>wait_backend_disconnected);
 
return 0;
 }
@@ -1219,6 +1235,8 @@ static void xlvbd_release_gendisk(struct blkfront_info 
*info)
 /* Already hold rinfo->ring_lock. */
 static inline void kick_pending_request_queues_locked(struct 
blkfront_ring_info *rinfo)
 {
+   if (unlikely(rinfo->dev_info->connected == BLKIF_STATE_FREEZING))
+   return;
if (!RING_FULL(>ring))
blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
 }
@@ -1342,8 +1360,6 @@ static void blkif_free_ring(struct blkfront_ring_info 
*rinfo)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
-   unsigned int i;
-
/* Prevent new requests being issued until we fix things up. */
info->connected = suspend ?
BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
@@ -1351,6 +1367,13 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
if (info->rq)
blk_mq_stop_hw_queues(info->rq);
 
+   

[Xen-devel] [RFC PATCH 12/12] PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA

[Anchal Agarwal]

From: Aleksei Besogonov 

The SNAPSHOT_SET_SWAP_AREA is supposed to be used to set the hibernation
offset on a running kernel to enable hibernating to a swap file.
However, it doesn't actually update the swsusp_resume_block variable. As
a result, the hibernation fails at the last step (after all the data is
written out) in the validation of the swap signature in
mark_swapfiles().

Before this patch, the command line processing was the only place where
swsusp_resume_block was set.

Signed-off-by: Aleksei Besogonov 
Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 kernel/power/user.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/power/user.c b/kernel/power/user.c
index abd2255..b522a42 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -379,8 +379,12 @@ static long snapshot_ioctl(struct file *filp, unsigned int 
cmd,
if (swdev) {
offset = swap_area.offset;
data->swap = swap_type_of(swdev, offset, NULL);
-   if (data->swap < 0)
+   if (data->swap < 0) {
error = -ENODEV;
+   } else {
+   swsusp_resume_device = swdev;
+   swsusp_resume_block = offset;
+   }
} else {
data->swap = -1;
error = -EINVAL;
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 00/12] Enable PM hibernation on guest VMs

[Anchal Agarwal]

Hello,
I am sending out a series of patches that implements guest
PM hibernation. These guests are running on xen hypervisor.
The patches had been tested against mainstream kernel and latest
xen version-4.11. EC2 instance hibernation feature is provided to
the AWS EC2 customers. PM hibernation uses swap space where
hibernation image is stored and restored from. I would like
the community to review and provide some feedback on the patch 
series and if they look good, merge them into 4.17 kernel.

Aleksei Besogonov (1):
  PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA

Anchal Agarwal (1):
  x86/xen: Introduce new function to map HYPERVISOR_shared_info on
Resume

Munehisa Kamata (10):
  xen/manage: keep track of the on-going suspend mode
  xen/manage: introduce helper function to know the on-going suspend
mode
  xenbus: add freeze/thaw/restore callbacks support
  x86/xen: add system core suspend and resume callbacks
  xen-blkfront: add callbacks for PM suspend and hibernation
  xen-netfront: add callbacks for PM suspend and hibernation support
  xen-time-introduce-xen_-save-restore-_steal_clock
  x86/xen: save and restore steal clock
  xen/events: add xen_shutdown_pirqs helper function
  x86/xen: close event channels for PIRQs in system core suspend
callback

 arch/x86/xen/enlighten_hvm.c  |   8 ++
 arch/x86/xen/suspend.c|  66 
 arch/x86/xen/time.c   |   3 +
 arch/x86/xen/xen-ops.h|   1 +
 drivers/block/xen-blkfront.c  | 158 --
 drivers/net/xen-netfront.c|  97 ++-
 drivers/xen/events/events_base.c  |  12 +++
 drivers/xen/manage.c  |  73 ++
 drivers/xen/time.c|  28 ++-
 drivers/xen/xenbus/xenbus_probe.c | 102 
 include/xen/events.h  |   1 +
 include/xen/xen-ops.h |   8 ++
 include/xen/xenbus.h  |   3 +
 kernel/power/user.c   |   6 +-
 14 files changed, 540 insertions(+), 26 deletions(-)

-- 
2.13.6


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

[Xen-devel] [RFC PATCH 04/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume

[Anchal Agarwal]

Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also  does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.

Signed-off-by: Anchal Agarwal 
Reviewed-by: Sebastian Biemueller 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
CR: https://cr.amazon.com/r/8273203/
---
 arch/x86/xen/enlighten_hvm.c | 7 +++
 arch/x86/xen/xen-ops.h   | 1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 754d5391d9fa..2c4bcf92a90a 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -24,6 +24,13 @@
 
 static unsigned long shared_info_pfn;
 
+void xen_hvm_map_shared_info(void)
+{
+   xen_hvm_init_shared_info();
+   if (shared_info_pfn)
+   HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
+}
+
 void xen_hvm_init_shared_info(void)
 {
struct xen_add_to_physmap xatp;
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index f377e1820c6c..94c8a009ab35 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -58,6 +58,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
+void xen_hvm_map_shared_info(void);
 void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
-- 
2.14.3


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

Re: [Xen-devel] [Qemu-devel] [PATCH v4 11/40] hw/xen: Use the IEC binary prefix definitions

[Eric Blake]

On 06/12/2018 03:51 PM, Richard Henderson wrote:

On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote:

  xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename \"%s\","
-  " size %" PRId64 " (%" PRId64 " MB)\n",
+  " size %" PRId64 " (%llu MB)\n",
blkdev->type, blkdev->fileproto, blkdev->filename,
-  blkdev->file_size, blkdev->file_size >> 20);
+  blkdev->file_size, blkdev->file_size / MiB);


Having to change printf markup is exactly why you shouldn't use ULL in MiB.


Conversely, M_BYTE was already ULL, so if you don't use it in MiB, 
you'll have to change other printf markup where you were changing those 
uses.


One benefit of using the widest possible type: we avoid risk of silent 
truncation.  Potential downsides: wasted processing time (when 32 bits 
was sufficient), and compilers might start warning when we narrow a 
64-bit value into a 32-bit variable (but I think we already ignore that).


One benefit of using the natural type that holds the value: use of 
64-bit math is explicit based on the type of what else is being 
multiplied by the macro.  Potential downside: 32*32 assigned to a 64-bit 
result may be botched (but hopefully Coverity will flag it).


So there's tradeoffs either way, and you at least need to document in 
your commit messages what auditing you have done that any type changes 
introduced by your changes are safe.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs

[Stefano Stabellini]

On Tue, 12 Jun 2018, Jan Beulich wrote:
> >> >> As a consequence of these changes, some options will become user-visible
> >> >> and not dependent on CONFIG_EXPERT. It does not mean that Xen Project
> >> >> will security support all possible combinations of kconfig options.
> >> >> Instead, there will be a small set of pre-canned configurations that
> >> >> will be supported.  See: 
> >> >> https://marc.info/?l=xen-devel=152424389512432 
> >> > 
> >> > George, Ian, Jan, shall SUPPORT.MD be updated to reflect the Kconfig 
> >> > changes?
> >> > 
> >> > I am mostly thinking about the board support and the fact that more 
> >> > options on Arm are selectable by the users.
> >> 
> >> I think that would be very desirable, yes.
> > 
> > Do you want me to add a patch for that to this series, or should I do it
> > separately?
> 
> I think such a doc change should be right in a particular patch making
> things user selectable.

I have added the following to patch #5, the one introducing all the UART
Kconfigs on ARM. I think it is the one introducing more new options. I
removed Julien's ACK because of this change. Let me know if you think we
need more details in SUPPORT.md.

diff --git a/SUPPORT.md b/SUPPORT.md
index 264b23f..e70f35c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -16,6 +16,18 @@ for the definitions of the support status levels etc.
 
 # Feature Support
 
+## Kconfig
+
+On x86, Kconfig options that depend on CONFIG_EXPERT are not security
+supported. Other Kconfig options that do not depend on CONFIG_EXPERT are
+supported, if the related features marked as supported in this document.
+
+On ARM, a wider range of Kconfig configurations is available to enable
+very small lines of code counts in the hypervisor. Not all possible
+combinations of kconfig options are security supported. Instead, a small
+set of pre-canned configurations is supported, see xen/arch/arm/configs.
+
+
 ## Host Architecture
 
 ### x86-64

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

[Xen-devel] TESTDAY report 4.11rc6

[pierre-philipp braun]

Hello!  Here is a success report for 4.11.0 rc6.  Better late than never, right?

## Hardware

- modern Lenovo V520-15IKL Desktop (i5-7400: 4 cores)
- old monster IBM 3850 M2 (x4 Xeon X7350: 16 cores)

I wish I had some Opterons available.

## Software (resp.)

- Devuan/ascii and Linux 4.17.0.slackxen
- Slackware64/14.2 and Linux 4.4.88.slackxen

Runs without Grub and without libvirt.

## Guest operating systems

- PV/ NetBSD 7.1 (XEN3_DOMU.201703111743Z)
- PV/ NetBSD 7.1.2 (XEN3_DOMU.201803151611Z)
- PV/ Ubuntu 16.04 LTS and Linux 4.4.0-21-generic
- HVM/ Devuan GNU/Linux 2.0 (ascii) and Linux 4.9.0-6-amd64

## Functionality tested

- PV & HVM/ xl create, shu, des
- HVM/ altp2m with LibVMI and Drakvuf (on the modern hardware only)
- blktap2 as `tap:tapdisk:aio` and `tap:qcow2`

## Comments

It feels great, as usual.  I am glad the `cr` alias for creating a guest is 
back.

I did not do any stress tests nor benchmarks.  This is just a basic report 
saying that nothing went wrong.  

Congratulations for the good and hard work.

## desktop xen dmesg

 Xen 4.11-rc
(XEN) Xen version 4.11-rc (root@example.local) (gcc (Debian 6.3.0-18+deb9u1) 
6.3.0 20170516) debug=y  Tue Jun 12 16:50:05 MSK 2018
(XEN) Latest ChangeSet: 
(XEN) Bootloader: SYSLINUX 6.03 20171017
(XEN) Command line: loglvl=all noreboot altp2m=1
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures

CPU Vendor: Intel, Family 6, Model 158, Stepping 9
DMI 3.0

## old monster xen dmesg

 Xen 4.11-rc
(XEN) Xen version 4.11-rc (root@example.local) (gcc (GCC) 5.3.0) debug=y  Tue 
Jun 12 22:49:41 MSK 2018
(XEN) Latest ChangeSet: 
(XEN) Bootloader: SYSLINUX 6.04 6.04-pre1-39-g2ea44cbe
(XEN) Command line: loglvl=all noreboot
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures

CPU Vendor: Intel, Family 6, Model 15, Stepping 11
DMI 2.4

## with a NetBSD dmesg on it

NetBSD 7.1.2 (INSTALL_XEN3_DOMU.201803151611Z)
total memory = 1 MB
avail memory = 9669 MB
kern.module.path=/stand/amd64/7.1/modules
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
hypervisor0 at mainbus0: Xen version 4.11-rc
VIRQ_DEBUG interrupt using event channel 3
vcpu0 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu1 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu2 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu3 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu4 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu5 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu6 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu7 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu8 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu9 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu10 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu11 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu12 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu13 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu14 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
vcpu15 at hypervisor0: Intel(R) Xeon(R) CPU   X7350  @ 2.93GHz, id 0x6fb
xenbus0 at hypervisor0: Xen Virtual Bus Interface
xencons0 at hypervisor0: Xen Virtual Console Driver
xencons0: console major 143, unit 0
xencons0: using event channel 2
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "xen_system_time" frequency 10 Hz quality 1
Xen clock: using event channel 5
Xen clock: using event channel 7
Xen clock: using event channel 9
Xen clock: using event channel 11
Xen clock: using event channel 13
Xen clock: using event channel 15
Xen clock: using event channel 17
Xen clock: using event channel 19
Xen clock: using event channel 21
Xen clock: using event channel 23
Xen clock: using event channel 25
Xen clock: using event channel 27
Xen clock: using event channel 29
Xen clock: using event channel 31
Xen clock: using event channel 33
Xen clock: using event channel 35
xenbus0: using event channel 1
xenbus: can't get state for device/suspend/event-channel (2)
xbd0 at xenbus0 id 51712: Xen Virtual Block Device Interface
xbd0: using event channel 36
xennet0 at xenbus0 id 0: Xen Virtual Network Interface
xennet0: MAC address 00:16:3e:47:5a:e9
xennet0: using event channel 37

[Xen-devel] [qemu-mainline test] 124093: tolerable FAIL - PUSHED

[osstest service owner]

flight 124093 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124093/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123987
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 123987
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123987
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 123987
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123987
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 123987
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu2afc4e3df80d947dd1bd42ce80278f591b35c74a
baseline version:
 qemuu0d2fa03dae4fbe185a082f361342b1e30aed4582

Last test of basis   123987  2018-06-09 06:34:28 Z3 days
Failing since124068  2018-06-11 12:07:31 Z1 days2 attempts
Testing same since   124093  2018-06-12 03:58:14 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Bruce Rogers 
  Jeff Cody 
  John Snow 
  Laurent Vivier 
  Mark Cave-Ayland 
  Max Reitz 
  Paolo Bonzini 
  Peter Maydell 
  Richard Henderson 
  Thomas Huth 
  Vladimir Sementsov-Ogievskiy 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf 

[Xen-devel] [RFC PATCH 08/12] xen-time-introduce-xen_-save-restore-_steal_clock

[Anchal Agarwal]

From: Munehisa Kamata 

Currently, steal time accounting code in scheduler expects steal clock
callback to provide monotonically increasing value. If the accounting
code receives a smaller value than previous one, it uses a negative
value to calculate steal time and results in incorrectly updated idle
and steal time accounting. This breaks userspace tools which read
/proc/stat.

top - 08:05:35 up  2:12,  3 users,  load average: 0.00, 0.07, 0.23
Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,30100.0%id,  0.0%wa,  0.0%hi, 
0.0%si,-1253874204672.0%st

This can actually happen when a Xen PVHVM guest gets restored from
hibernation, because such a restored guest is just a fresh domain from
Xen perspective and the time information in runstate info starts over
from scratch.

This patch introduces xen_save_steal_clock() which saves current values
in runstate info into per-cpu variables. Its couterpart,
xen_restore_steal_clock(), sets offset if it found the current values in
runstate info are smaller than previous ones. xen_steal_clock() is also
modified to use the offset to ensure that scheduler only sees
monotonically increasing number.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 drivers/xen/time.c| 28 +++-
 include/xen/xen-ops.h |  2 ++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 3e741cd..4756042 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -20,6 +20,8 @@
 
 /* runstate info updated by Xen */
 static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
+static DEFINE_PER_CPU(u64, xen_prev_steal_clock);
+static DEFINE_PER_CPU(u64, xen_steal_clock_offset);
 
 static DEFINE_PER_CPU(u64[4], old_runstate_time);
 
@@ -149,7 +151,7 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
 }
 
-u64 xen_steal_clock(int cpu)
+static u64 __xen_steal_clock(int cpu)
 {
struct vcpu_runstate_info state;
 
@@ -157,6 +159,30 @@ u64 xen_steal_clock(int cpu)
return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
 }
 
+u64 xen_steal_clock(int cpu)
+{
+   return __xen_steal_clock(cpu) + per_cpu(xen_steal_clock_offset, cpu);
+}
+
+void xen_save_steal_clock(int cpu)
+{
+   per_cpu(xen_prev_steal_clock, cpu) = xen_steal_clock(cpu);
+}
+
+void xen_restore_steal_clock(int cpu)
+{
+   u64 steal_clock = __xen_steal_clock(cpu);
+
+   if (per_cpu(xen_prev_steal_clock, cpu) > steal_clock) {
+   /* Need to update the offset */
+   per_cpu(xen_steal_clock_offset, cpu) =
+   per_cpu(xen_prev_steal_clock, cpu) - steal_clock;
+   } else {
+   /* Avoid unnecessary steal clock warp */
+   per_cpu(xen_steal_clock_offset, cpu) = 0;
+   }
+}
+
 void xen_setup_runstate_info(int cpu)
 {
struct vcpu_register_runstate_memory_area area;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 65f25bd..10330f8 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -36,6 +36,8 @@ void xen_time_setup_guest(void);
 void xen_manage_runstate_time(int action);
 void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
 u64 xen_steal_clock(int cpu);
+void xen_save_steal_clock(int cpu);
+void xen_restore_steal_clock(int cpu);
 
 int xen_setup_shutdown_event(void);
 
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 11/12] x86/xen: close event channels for PIRQs in system core suspend callback

[Anchal Agarwal]

From: Munehisa Kamata 

Close event channels allocated for devices which are backed by PIRQ and
still active when suspending the system core. Normally, the devices are
emulated legacy devices, e.g. PS/2 keyboard, floppy controller and etc.

Without this, in PM hibernation, information about the event channel
remains in hibernation image, but there is no guarantee that the same
event channel numbers are assigned to the devices when restoring the
system. This may cause conflict like the following and prevent some
devices from being restored correctly.

[  102.330821] [ cut here ]
[  102.333264] WARNING: CPU: 0 PID: 2324 at
drivers/xen/events/events_base.c:878 bind_evtchn_to_irq+0x88/0xf0
...
[  102.348057] Call Trace:
[  102.348057]  [] dump_stack+0x63/0x84
[  102.348057]  [] __warn+0xd1/0xf0
[  102.348057]  [] warn_slowpath_null+0x1d/0x20
[  102.348057]  [] bind_evtchn_to_irq+0x88/0xf0
[  102.348057]  [] ? blkif_copy_from_grant+0xb0/0xb0 
[xen_blkfront]
[  102.348057]  [] bind_evtchn_to_irqhandler+0x27/0x80
[  102.348057]  [] talk_to_blkback+0x425/0xcd0 [xen_blkfront]
[  102.348057]  [] ? __kmalloc+0x1ea/0x200
[  102.348057]  [] blkfront_restore+0x2d/0x60 [xen_blkfront]
[  102.348057]  [] xenbus_dev_restore+0x58/0x100
[  102.348057]  [] ?  xenbus_frontend_delayed_resume+0x20/0x20
[  102.348057]  [] xenbus_dev_cond_restore+0x1e/0x30
[  102.348057]  [] dpm_run_callback+0x4e/0x130
[  102.348057]  [] device_resume+0xe7/0x210
[  102.348057]  [] ? pm_dev_dbg+0x80/0x80
[  102.348057]  [] dpm_resume+0x114/0x2f0
[  102.348057]  [] hibernation_snapshot+0x15f/0x380
[  102.348057]  [] hibernate+0x183/0x290
[  102.348057]  [] state_store+0xcf/0xe0
[  102.348057]  [] kobj_attr_store+0xf/0x20
[  102.348057]  [] sysfs_kf_write+0x3a/0x50
[  102.348057]  [] kernfs_fop_write+0x10b/0x190
[  102.348057]  [] __vfs_write+0x28/0x120
[  102.348057]  [] ? rw_verify_area+0x49/0xb0
[  102.348057]  [] vfs_write+0xb2/0x1b0
[  102.348057]  [] SyS_write+0x46/0xa0
[  102.348057]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
[  102.423005] ---[ end trace b8d6718e22e2b107 ]---
[  102.425031] genirq: Flags mismatch irq 6.  (blkif) vs.  
(floppy)

Note that we don't explicitly re-allocate event channels for such
devices in the resume callback. Re-allocation will occur when PM core
re-enable IRQs for the devices at later point.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 arch/x86/xen/suspend.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index dae0f74..affa63d 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -105,6 +105,8 @@ static int xen_syscore_suspend(void)
xen_save_steal_clock(cpu);
}
 
+   xen_shutdown_pirqs();
+
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
 
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 07/12] xen-netfront: add callbacks for PM suspend and hibernation support

[Anchal Agarwal]

From: Munehisa Kamata 

Add freeze and restore callbacks for PM suspend and hibernation support.
The freeze handler simply disconnects the frotnend from the backend and
frees resources associated with queues after disabling the net_device
from the system. The restore handler just changes the frontend state and
let the xenbus handler to re-allocate the resources and re-connect to the
backend. This can be performed transparently to the rest of the system.
The handlers are used for both PM suspend and hibernation so that we can
keep the existing suspend/resume callbacks for Xen suspend without
modification. Freezing netfront devices is normally expected to finish within a 
few
hundred milliseconds, but it can rarely take more than 5 seconds and
hit the hard coded timeout, it would depend on backend state which may
be congested and/or have complex configuration. While it's rare case,
longer default timeout seems a bit more reasonable here to avoid hitting
the timeout. Also, make it configurable via module parameter so that we
can cover broader setups than what we know currently.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Eduardo Valentin 
Reviewed-by: Munehisa Kamata 
---
 drivers/net/xen-netfront.c | 97 +-
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 4dd0668..4ea9284 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -56,6 +57,12 @@
 #include 
 #include 
 
+enum netif_freeze_state {
+   NETIF_FREEZE_STATE_UNFROZEN,
+   NETIF_FREEZE_STATE_FREEZING,
+   NETIF_FREEZE_STATE_FROZEN,
+};
+
 /* Module parameters */
 #define MAX_QUEUES_DEFAULT 8
 static unsigned int xennet_max_queues;
@@ -63,6 +70,12 @@ module_param_named(max_queues, xennet_max_queues, uint, 
0644);
 MODULE_PARM_DESC(max_queues,
 "Maximum number of queues per virtual interface");
 
+static unsigned int netfront_freeze_timeout_secs = 10;
+module_param_named(freeze_timeout_secs,
+  netfront_freeze_timeout_secs, uint, 0644);
+MODULE_PARM_DESC(freeze_timeout_secs,
+"timeout when freezing netfront device in seconds");
+
 static const struct ethtool_ops xennet_ethtool_ops;
 
 struct netfront_cb {
@@ -160,6 +173,10 @@ struct netfront_info {
struct netfront_stats __percpu *tx_stats;
 
atomic_t rx_gso_checksum_fixup;
+
+   int freeze_state;
+
+   struct completion wait_backend_disconnected;
 };
 
 struct netfront_rx_info {
@@ -723,6 +740,21 @@ static int xennet_close(struct net_device *dev)
return 0;
 }
 
+static int xennet_disable_interrupts(struct net_device *dev)
+{
+   struct netfront_info *np = netdev_priv(dev);
+   unsigned int num_queues = dev->real_num_tx_queues;
+   unsigned int i;
+   struct netfront_queue *queue;
+
+   for (i = 0; i < num_queues; ++i) {
+   queue = >queues[i];
+   disable_irq(queue->tx_irq);
+   disable_irq(queue->rx_irq);
+   }
+   return 0;
+}
+
 static void xennet_move_rx_slot(struct netfront_queue *queue, struct sk_buff 
*skb,
grant_ref_t ref)
 {
@@ -1296,6 +1328,8 @@ static struct net_device *xennet_create_dev(struct 
xenbus_device *dev)
 
np->queues = NULL;
 
+   init_completion(>wait_backend_disconnected);
+
err = -ENOMEM;
np->rx_stats = netdev_alloc_pcpu_stats(struct netfront_stats);
if (np->rx_stats == NULL)
@@ -1782,6 +1816,50 @@ static int xennet_create_queues(struct netfront_info 
*info,
return 0;
 }
 
+static int netfront_freeze(struct xenbus_device *dev)
+{
+   struct netfront_info *info = dev_get_drvdata(>dev);
+   unsigned long timeout = netfront_freeze_timeout_secs * HZ;
+   int err = 0;
+
+   xennet_disable_interrupts(info->netdev);
+
+   netif_device_detach(info->netdev);
+
+   info->freeze_state = NETIF_FREEZE_STATE_FREEZING;
+
+   /* Kick the backend to disconnect */
+   xenbus_switch_state(dev, XenbusStateClosing);
+
+   /* We don't want to move forward before the frontend is diconnected
+* from the backend cleanly.
+*/
+   timeout = wait_for_completion_timeout(>wait_backend_disconnected,
+ timeout);
+   if (!timeout) {
+   err = -EBUSY;
+   xenbus_dev_error(dev, err, "Freezing timed out;"
+"the device may become inconsistent state");
+   return err;
+   }
+
+   /* Tear down queues */
+   xennet_disconnect_backend(info);
+   xennet_destroy_queues(info);
+
+   info->freeze_state = NETIF_FREEZE_STATE_FROZEN;
+
+   return err;
+}
+
+static int netfront_restore(struct xenbus_device *dev)
+{
+   /* Kick the backend to 

[Xen-devel] [RFC PATCH 10/12] xen/events: add xen_shutdown_pirqs helper function

[Anchal Agarwal]

From: Munehisa Kamata 

Add a simple helper function to "shutdown" active PIRQs, which actually
closes event channels but keeps related IRQ structures intact. PM
suspend/hibernation code will rely on this.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Anchal Agarwal 
Reviewed-by: Munehisa Kamata 
Reviewed-by: Eduardo Valentin 
---
 drivers/xen/events/events_base.c | 12 
 include/xen/events.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 762378f..88137c8 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1581,6 +1581,18 @@ void xen_irq_resume(void)
restore_pirqs();
 }
 
+void xen_shutdown_pirqs(void)
+{
+   struct irq_info *info;
+
+   list_for_each_entry(info, _irq_list_head, list) {
+   if (info->type != IRQT_PIRQ || !VALID_EVTCHN(info->evtchn))
+   continue;
+
+   shutdown_pirq(irq_get_irq_data(info->irq));
+   }
+}
+
 static struct irq_chip xen_dynamic_chip __read_mostly = {
.name   = "xen-dyn",
 
diff --git a/include/xen/events.h b/include/xen/events.h
index c3e6bc6..e4d5ccb 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -70,6 +70,7 @@ static inline void notify_remote_via_evtchn(int port)
 void notify_remote_via_irq(int irq);
 
 void xen_irq_resume(void);
+void xen_shutdown_pirqs(void);
 
 /* Clear an irq's pending state, in preparation for polling on it */
 void xen_clear_irq_pending(int irq);
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v5 3/3] Input: xen-kbdfront - allow better run-time configuration

[Dmitry Torokhov]

On Tue, Jun 12, 2018 at 10:48:56AM +0300, Oleksandr Andrushchenko wrote:
>  
> + if (!(with_kbd | with_ptr | with_mtouch)) {

I changed this to logical "OR" and applied, thank you.

> + ret = -ENXIO;
> + goto error;
> + }
> +
>   ret = xenkbd_connect_backend(dev, info);
>   if (ret < 0)
>   goto error;
> -- 
> 2.17.1
> 

-- 
Dmitry

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

Re: [Xen-devel] [PATCH v5 07/10] arm: add a tiny kconfig configuration

[Julien Grall]

On 12/06/2018 20:41, Stefano Stabellini wrote:

On Tue, 12 Jun 2018, Julien Grall wrote:

Hi,

On 12/06/18 16:55, Stefano Stabellini wrote:

On Tue, 12 Jun 2018, Julien Grall wrote:

Hi Stefano,

On 12/06/18 01:50, Stefano Stabellini wrote:

On Tue, 5 Jun 2018, Julien Grall wrote:

Hi Stefano,

On 04/06/18 18:24, Stefano Stabellini wrote:

Add a tiny kconfig configuration. Enabled NULL and Credit
schedulers.
Support only 8 cpus. It only carries non-default options (use make


I don't see where 8 CPUs would only be supported as the default value
is
128
cpus.

I need to update the commit message reflecting the changes to the
patch



olddefconfig to produce a complete .config file).


With all the series I did the following things:
1) copy tiny.config to .config
2) make olddefconfig
3) make menuconfig and select QEMU

After 1) the numbers of CPUs are set to 128. After 3) I would expect
the
number of CPUs to go down to 8. Unfortunately this is not the cases.

So your command does not seem to be enough here.


NR_CPUS cannot go down. It is a limitation of Kconfig, similar to the
fact that option cannot be de-selected.

It is not 1) that sets NR_CPUS to 128, it would be 2) above. For this to
work you have to skip 2) and just do:

- copy tiny.config to .config
- make menuconfig and select QEMU


Well I suggested a way during one of our recent chat and I am a bit
surprised
this was not considered here.

For reminder, the way was to provide a makefile target that will select
tiny
and the platform at the same time.

make tiny_defconfig PLAT=qemu


I prefer not to add additional targets


I think it would make easier for user to select any config and the platform.
It is one command over 3 that can mistakenly be misused.

Anyway, sooner or later we will want to have such target in Xen.


Feel like writing a small patch for it? I would be happy to include it
:-)


I have a 12h flight on Friday, I might have a look to kill the time :).

Cheers,






--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 07/13] xen/arm: Simplify alternative patching of non-writable region

[Julien Grall]

Hi Konrad,

On 12/06/2018 22:17, Konrad Rzeszutek Wilk wrote:

On Tue, Jun 12, 2018 at 12:36:37PM +0100, Julien Grall wrote:

During the MMU setup process, Xen will set SCTLR_EL2.WNX
(Write-Non-eXecutable) bit. Because of that, the alternative code need
to re-mapped the region in a difference place in order to modify the
text section.

At the moment, the function patching the code is only aware of the
re-mapped region. This requires the caller to mess with Xen internal in
order to have function such as is_active_kernel_text() working.

All the interactions with Xen internal can be removed by specifying the
offset between the region patch and the writable region for updating the
instruction

This simplification will also make it easier to integrate dynamic patching
in a follow-up patch. Indeed, the callback address should be in
an original region and not re-mapped only which is writeable non-executable.

This is part of XSA-263.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---

Cc: Konrad Rzeszutek Wilk 

 Changes in v3:
 - Add stefano's reviewed-by

 Changes in v2:
 - Add commit message
 - Remove comment in the code that does not make sense anymore
---
  xen/arch/arm/alternative.c | 42 +-
  1 file changed, 13 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 9ffdc475d6..936cf04956 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
  /*
   * The region patched should be read-write to allow __apply_alternatives
   * to replacing the instructions when necessary.
+ *
+ * @update_offset: Offset between the region patched and the writable
+ * region for the update. 0 if the patched region is writable.
   */
-static int __apply_alternatives(const struct alt_region *region)
+static int __apply_alternatives(const struct alt_region *region,
+paddr_t update_offset)
  {
  const struct alt_instr *alt;
-const u32 *replptr;
-u32 *origptr;
+const u32 *replptr, *origptr;
+u32 *updptr;
  
  printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",

 region->begin, region->end);
@@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region 
*region)
  BUG_ON(alt->alt_len != alt->orig_len);
  
  origptr = ALT_ORIG_PTR(alt);

+updptr = (void *)origptr + update_offset;
  replptr = ALT_REPL_PTR(alt);
  
  nr_inst = alt->alt_len / sizeof(insn);

@@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region 
*region)
  for ( i = 0; i < nr_inst; i++ )
  {
  insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(origptr + i) = cpu_to_le32(insn);
+*(updptr + i) = cpu_to_le32(insn);
  }
  
  /* Ensure the new instructions reached the memory and nuke */

@@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
  paddr_t xen_size = _end - _start;
  unsigned int xen_order = get_order_from_bytes(xen_size);
  void *xenmap;
-struct virtual_region patch_region = {
-.list = LIST_HEAD_INIT(patch_region.list),
-};
  
  BUG_ON(patched);
  
@@ -177,31 +179,13 @@ static int __apply_alternatives_multi_stop(void *unused)

  /* Re-mapping Xen is not expected to fail during boot. */
  BUG_ON(!xenmap);
  
-/*

- * If we generate a new branch instruction, the target will be
- * calculated in this re-mapped Xen region. So we have to register
- * this re-mapped Xen region as a virtual region temporarily.


What about this?

Won't this mean the traps (if there are any) won't be recognized at all
during this patching?


What do you mean by recognized? This new region will only be accessed to 
write instruction. The only potential fault on that region is a data abort.


So I am not sure why we would need to register it as a virtual region here.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs

[Julien Grall]

Hi Stefano,

On 12/06/2018 20:53, Stefano Stabellini wrote:

On Tue, 12 Jun 2018, Jan Beulich wrote:

As a consequence of these changes, some options will become user-visible
and not dependent on CONFIG_EXPERT. It does not mean that Xen Project
will security support all possible combinations of kconfig options.
Instead, there will be a small set of pre-canned configurations that
will be supported.  See: https://marc.info/?l=xen-devel=152424389512432


George, Ian, Jan, shall SUPPORT.MD be updated to reflect the Kconfig
changes?

I am mostly thinking about the board support and the fact that more
options on Arm are selectable by the users.


I think that would be very desirable, yes.


Do you want me to add a patch for that to this series, or should I do it
separately?


I think such a doc change should be right in a particular patch making
things user selectable.


I have added the following to patch #5, the one introducing all the UART
Kconfigs on ARM. I think it is the one introducing more new options. I
removed Julien's ACK because of this change. Let me know if you think we
need more details in SUPPORT.md.

diff --git a/SUPPORT.md b/SUPPORT.md
index 264b23f..e70f35c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -16,6 +16,18 @@ for the definitions of the support status levels etc.
  
  # Feature Support
  
+## Kconfig

+
+On x86, Kconfig options that depend on CONFIG_EXPERT are not security
+supported. Other Kconfig options that do not depend on CONFIG_EXPERT are
+supported, if the related features marked as supported in this document.
+
+On ARM, a wider range of Kconfig configurations is available to enable
+very small lines of code counts in the hypervisor. Not all possible
+combinations of kconfig options are security supported. Instead, a small
+set of pre-canned configurations is supported, see xen/arch/arm/configs.


I think we need to be more specific about CONFIG_EXPERT=y. This is still 
something we don't want to security support on Arm.


Furthermore, tiny.config by default will select the platform "ALL" but 
most of the user will tailor to a specific platform. That platform will 
select drivers. By reading your statement, this new config will not be 
security supported. Not sure if it is wanted.


This also made me realize that in your tiny config you select NULL 
scheduler which is still marked as experimental in the Kconfig. It feels 
strange that you security support it in the tiny.config but not by default.


Cheers,

--
Julien Grall

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