[Xen-devel] [RFC PATCH 7/9] x86/SVM: Add vcpu scheduling support for AVIC

[Suravee Suthikulpanit]

Add hooks to manage AVIC data structure during vcpu scheduling.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/avic.c | 82 +
 xen/arch/x86/hvm/svm/svm.c  | 10 ++
 2 files changed, 92 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index 90df181..cd8a9d4 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -45,6 +45,83 @@ avic_get_phy_ait_entry(struct vcpu *v, int index)
 }
 
 /***
+ * AVIC VCPU SCHEDULING
+ */
+static void avic_vcpu_load(struct vcpu *v)
+{
+struct arch_svm_struct *s = >arch.hvm_svm;
+int h_phy_apic_id;
+struct svm_avic_phy_ait_entry entry;
+
+if ( !svm_avic || !s->avic_phy_id_cache )
+return;
+
+if ( test_bit(_VPF_blocked, >pause_flags) )
+return;
+
+/* Note: APIC ID = 0xff is used for broadcast.
+ *   APIC ID > 0xff is reserved.
+ */
+h_phy_apic_id = cpu_data[v->processor].apicid;
+if ( h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX )
+return;
+
+entry = *(s->avic_phy_id_cache);
+smp_rmb();
+entry.host_phy_apic_id = h_phy_apic_id;
+entry.is_running = 1;
+*(s->avic_phy_id_cache) = entry;
+smp_wmb();
+}
+
+static void avic_vcpu_put(struct vcpu *v)
+{
+struct arch_svm_struct *s = >arch.hvm_svm;
+struct svm_avic_phy_ait_entry entry;
+
+if ( !svm_avic || !s->avic_phy_id_cache )
+return;
+
+entry = *(s->avic_phy_id_cache);
+smp_rmb();
+entry.is_running = 0;
+*(s->avic_phy_id_cache) = entry;
+smp_wmb();
+}
+
+static void avic_vcpu_resume(struct vcpu *v)
+{
+struct svm_avic_phy_ait_entry entry;
+struct arch_svm_struct *s = >arch.hvm_svm;
+
+if ( !svm_avic_vcpu_enabled(v) || !s->avic_phy_id_cache )
+return;
+
+ASSERT(!test_bit(_VPF_blocked, >pause_flags));
+
+entry = *(s->avic_phy_id_cache);
+smp_rmb();
+entry.is_running = 1;
+*(s->avic_phy_id_cache)= entry;
+smp_wmb();
+}
+
+static void avic_vcpu_block(struct vcpu *v)
+{
+struct svm_avic_phy_ait_entry entry;
+struct arch_svm_struct *s = >arch.hvm_svm;
+
+if ( !svm_avic_vcpu_enabled(v) || !s->avic_phy_id_cache )
+return;
+
+entry = *(s->avic_phy_id_cache);
+smp_rmb();
+entry.is_running = 0;
+*(s->avic_phy_id_cache) = entry;
+smp_wmb();
+}
+
+/***
  * AVIC APIs
  */
 int svm_avic_dom_init(struct domain *d)
@@ -97,6 +174,11 @@ int svm_avic_dom_init(struct domain *d)
 clear_domain_page(_mfn(mfn));
 d->arch.hvm_domain.svm.avic_phy_ait_mfn = mfn;
 
+d->arch.hvm_domain.pi_ops.pi_switch_to = avic_vcpu_put;
+d->arch.hvm_domain.pi_ops.pi_switch_from = avic_vcpu_load;
+d->arch.hvm_domain.pi_ops.vcpu_block = avic_vcpu_block;
+d->arch.hvm_domain.pi_ops.pi_do_resume = avic_vcpu_resume;
+
 return ret;
 err_out:
 svm_avic_dom_destroy(d);
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 409096a..aafbfa1 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1011,6 +1011,10 @@ static void svm_ctxt_switch_from(struct vcpu *v)
 svm_tsc_ratio_save(v);
 
 svm_sync_vmcb(v);
+
+if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_from )
+v->domain->arch.hvm_domain.pi_ops.pi_switch_from(v);
+
 svm_vmload(per_cpu(root_vmcb, cpu));
 
 /* Resume use of ISTs now that the host TR is reinstated. */
@@ -1050,6 +1054,9 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 svm_lwp_load(v);
 svm_tsc_ratio_load(v);
 
+if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_to )
+v->domain->arch.hvm_domain.pi_ops.pi_switch_to(v);
+
 if ( cpu_has_rdtscp )
 wrmsrl(MSR_TSC_AUX, hvm_msr_tsc_aux(v));
 }
@@ -1095,6 +1102,9 @@ static void noreturn svm_do_resume(struct vcpu *v)
 vmcb_set_vintr(vmcb, intr);
 }
 
+if ( v->domain->arch.hvm_domain.pi_ops.pi_do_resume )
+v->domain->arch.hvm_domain.pi_ops.pi_do_resume(v);
+
 hvm_do_resume(v);
 
 reset_stack_and_jump(svm_asm_do_resume);
-- 
1.9.1


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

[Xen-devel] [RFC PATCH 0/9] Introduce AMD SVM AVIC

[Suravee Suthikulpanit]

GITHUB
==
Latest git tree can be found at:
http://github.com/ssuthiku/xen.gitxen_avic_part1_v1

OVERVIEW

This patch set is the first of the two-part patch series to introduce 
the new AMD Advance Virtual Interrupt Controller (AVIC) support.

Basically, SVM AVIC hardware virtualizes local APIC registers of each
vCPU via the virtual APIC (vAPIC) backing page. This allows guest access
to certain APIC registers without the need to emulate the hardware behavior
in the hypervisor. More information about AVIC can be found in the
AMD64 Architecture Programmer???s Manual Volume 2 - System Programming.

  http://support.amd.com/TechDocs/24593.pdf

For SVM AVIC, we extend the existing kvm_amd driver to:
  * Check CPUID to detect AVIC support in the processor
  * Program new fields in VMCB to enable AVIC
  * Introduce new AVIC data structures and add code to manage them
  * Handle two new AVIC #VMEXITs
  * Add new interrupt injection code using vAPIC backing page
instead of the existing V_IRQ, V_INTR_PRIO, V_INTR_VECTOR,
and V_IGN_TPR fields

Currently, this patch series does not enable AVIC by default.
Users can enable SVM AVIC by specifying Xen parameter svm-avic=1.

Later, in part 2, we will introduce the IOMMU AVIC support, which
provides speed up for PCI device pass-through use case by allowing
the IOMMU hardware to inject interrupt directly into the guest via
the vAPIC backing page.

OVERALL PERFORMANCE
===
Currently, AVIC is available on the AMD family 15h models 6Xh
(Carrizo) processors and newer. Here, the Carizzo is used to collect
performance data shown below.

Generally, SVM AVIC alone (w/o IOMMU AVIC) should provide overall speed up
for HVM guest since it does not require #vmexit into the hypervisor to
emulate certain guest accesses to local APIC registers.

It should also improve performance when hypervisor wants to inject
interrupts into a running vcpu by setting the corresponded IRR
bit in the vAPIC backing page and trigger AVIC_DOORBELL MSR.

For sending IPI interrupts between running vcpus in Linux guest,
Xen is default to using event channel.  However, in case of
non-paravirtualize guest, AVIC can also provide performance
improvements for sending IPI.

BENCHMARK 1: HACKBENCH
==

For measuring IPI performance used for scheduling workload, I have collected
some performance number on 2 and 3 CPU running hackbech with the following
detail:

  hackbench -p -l 10
  Running in process mode with 10 groups using 40 file descriptors each (== 400 
tasks)
  Each sender will pass 10 messages of 100 bytes

   |  2 vcpus (sec) |  3 vcpus (sec)   
  
No AVIC w/o evtchn | 299.57 |337.779
No AVIC w/  evtchn | 270.37 |419.6064 
   AVIC w/  evtchn | 181.46 |171.7957
   AVIC w/o evtchn | 171.81 |169.0858

Note: In "w/o evtchn" case, the Linux guest is built w/o
  Xen guest support.

CURRENT UNTESTED USE-CASES
===
- Nested VM

Any feedback and comments are very much appreciated.

Thank you,
Suravee

Suravee Suthikulpanit (9):
  x86/HVM: Introduce struct hvm_pi_ops
  x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as
non-static
  x86/HVM: Call vlapic_destroy after vcpu_destroy
  x86/SVM: Modify VMCB fields to add AVIC support
  x86/HVM/SVM: Add AVIC initialization code
  x86/SVM: Add AVIC vmexit handlers
  x86/SVM: Add vcpu scheduling support for AVIC
  x86/SVM: Add interrupt management code via AVIC
  x86/SVM: Hook up miscellaneous AVIC functions

 xen/arch/x86/hvm/hvm.c |   4 +-
 xen/arch/x86/hvm/svm/Makefile  |   1 +
 xen/arch/x86/hvm/svm/avic.c| 609 +
 xen/arch/x86/hvm/svm/intr.c|   4 +
 xen/arch/x86/hvm/svm/svm.c |  57 +++-
 xen/arch/x86/hvm/svm/vmcb.c|   9 +-
 xen/arch/x86/hvm/vlapic.c  |   5 +-
 xen/arch/x86/hvm/vmx/vmx.c |  32 +-
 xen/include/asm-x86/hvm/domain.h   |  63 
 xen/include/asm-x86/hvm/hvm.h  |   4 +-
 xen/include/asm-x86/hvm/svm/avic.h |  49 +++
 xen/include/asm-x86/hvm/svm/svm.h  |   2 +
 xen/include/asm-x86/hvm/svm/vmcb.h |  35 ++-
 xen/include/asm-x86/hvm/vlapic.h   |   4 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  59 
 15 files changed, 843 insertions(+), 94 deletions(-)
 create mode 100644 xen/arch/x86/hvm/svm/avic.c
 create mode 100644 xen/include/asm-x86/hvm/svm/avic.h

-- 
1.9.1


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

[Xen-devel] [RFC PATCH 9/9] x86/SVM: Hook up miscellaneous AVIC functions

[Suravee Suthikulpanit]

Hook up virtual_intr_delivery_enabled and deliver_posted_intr functions
when AVIC is enabled.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c | 10 ++
 xen/include/asm-x86/hvm/svm/avic.h |  5 +
 2 files changed, 15 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index caf9984..a9c09a7 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1495,6 +1495,16 @@ const struct hvm_function_table * __init start_svm(void)
 svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
 ((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
 
+if ( !cpu_has_svm_avic )
+svm_avic = 0;
+
+if ( svm_avic )
+{
+svm_function_table.deliver_posted_intr  = svm_avic_deliver_posted_intr,
+svm_function_table.virtual_intr_delivery_enabled = svm_avic_enabled,
+printk("SVM: AVIC enabled\n");
+}
+
 return _function_table;
 }
 
diff --git a/xen/include/asm-x86/hvm/svm/avic.h 
b/xen/include/asm-x86/hvm/svm/avic.h
index e1eb66c..8411854 100644
--- a/xen/include/asm-x86/hvm/svm/avic.h
+++ b/xen/include/asm-x86/hvm/svm/avic.h
@@ -41,4 +41,9 @@ void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs 
*regs);
 void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs);
 
 void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vector);
+
+static inline int svm_avic_enabled(void)
+{
+return svm_avic;
+}
 #endif /* _SVM_AVIC_H_ */
-- 
1.9.1


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

[Xen-devel] [RFC PATCH 8/9] x86/SVM: Add interrupt management code via AVIC

[Suravee Suthikulpanit]

Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR,
and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch
introduces new interrupt injection code via AVIC backing page.

Also, the AVIC hardware automatically synchronizes TPR and CR8/vTPR, when
values are updated. Therefore, xen does not need to handle this when enable
AVIC.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/avic.c| 31 +++
 xen/arch/x86/hvm/svm/intr.c|  4 
 xen/arch/x86/hvm/svm/svm.c | 12 ++--
 xen/arch/x86/hvm/svm/vmcb.c|  6 +-
 xen/include/asm-x86/hvm/svm/avic.h |  1 +
 5 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index cd8a9d4..4144223 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -576,3 +576,34 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs)
 
 return;
 }
+
+/***
+ * AVIC INTR INJECTION
+ */
+void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
+{
+struct vlapic *vlapic = vcpu_vlapic(v);
+
+/* Fallback to use non-AVIC if vcpu is not enabled with AVIC */
+if ( !svm_avic_vcpu_enabled(v) )
+{
+if ( !vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
+vcpu_kick(v);
+return;
+}
+
+if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
+return;
+
+if ( vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
+return;
+
+/*
+ * If vcpu is running on another cpu, hit the doorbell to signal
+ * it to process interrupt. Otherwise, kick it.
+ */
+if ( v->is_running && (v != current) )
+wrmsrl(AVIC_DOORBELL, cpu_data[v->processor].apicid);
+else
+vcpu_kick(v);
+}
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index bd94731..876d2ad 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include  /* for nestedhvm_vcpu_in_guestmode */
@@ -101,6 +102,9 @@ static void svm_enable_intr_window(struct vcpu *v, struct 
hvm_intack intack)
 HVMTRACE_3D(INTR_WINDOW, intack.vector, intack.source,
 vmcb->eventinj.fields.v?vmcb->eventinj.fields.vector:-1);
 
+if ( svm_avic_vcpu_enabled(v) )
+return;
+
 /*
  * Create a dummy virtual interrupt to intercept as soon as the
  * guest can accept the real interrupt.
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index aafbfa1..caf9984 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1091,7 +1091,8 @@ static void noreturn svm_do_resume(struct vcpu *v)
 hvm_asid_flush_vcpu(v);
 }
 
-if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) &&
+ !svm_avic_vcpu_enabled(v) )
 {
 vintr_t intr;
 
@@ -2337,7 +2338,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * NB. We need to preserve the low bits of the TPR to make checked builds
  * of Windows work, even though they don't actually do anything.
  */
-if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) &&
+ !svm_avic_vcpu_enabled(v) )
 {
 intr = vmcb_get_vintr(vmcb);
 vlapic_set_reg(vlapic, APIC_TASKPRI,
@@ -2530,6 +2532,12 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
 intr = vmcb_get_vintr(vmcb);
 
+if ( svm_avic_vcpu_enabled(v) )
+{
+gdprintk(XENLOG_ERR, "AVIC VINTR:\n");
+domain_crash(v->domain);
+}
+
 intr.fields.irq = 0;
 general1_intercepts &= ~GENERAL1_INTERCEPT_VINTR;
 
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 9ee7fc7..9ea7627 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -93,10 +93,14 @@ static int construct_vmcb(struct vcpu *v)
 vmcb->_dr_intercepts = ~0u;
 
 /* Intercept all control-register accesses except for CR2 and CR8. */
-vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ |
+if ( !svm_avic_vcpu_enabled(v) )
+vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ |
  CR_INTERCEPT_CR2_WRITE |
  CR_INTERCEPT_CR8_READ |
  CR_INTERCEPT_CR8_WRITE);
+else
+vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ |
+ CR_INTERCEPT_CR2_WRITE );
 
 /* I/O and MSR permission bitmaps. */
 arch_svm->msrpm = alloc_xenheap_pages(get_order_from_bytes(MSRPM_SIZE), 0);
diff --git a/xen/include/asm-x86/hvm/svm/avic.h 

[Xen-devel] [RFC PATCH 2/9] x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as non-static

[Suravee Suthikulpanit]

Expose vlapic_read_aligned and vlapic_reg_write() to be used by AVIC.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/vlapic.c| 5 ++---
 xen/include/asm-x86/hvm/vlapic.h | 4 
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 1d5d287..0f52067 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -562,7 +562,7 @@ static void vlapic_set_tdcr(struct vlapic *vlapic, unsigned 
int val)
 "timer_divisor: %d", vlapic->hw.timer_divisor);
 }
 
-static uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int offset)
+uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int offset)
 {
 switch ( offset )
 {
@@ -680,8 +680,7 @@ static void vlapic_tdt_pt_cb(struct vcpu *v, void *data)
 vcpu_vlapic(v)->hw.tdt_msr = 0;
 }
 
-static void vlapic_reg_write(struct vcpu *v,
- unsigned int offset, uint32_t val)
+void vlapic_reg_write(struct vcpu *v, unsigned int offset, uint32_t val)
 {
 struct vlapic *vlapic = vcpu_vlapic(v);
 
diff --git a/xen/include/asm-x86/hvm/vlapic.h b/xen/include/asm-x86/hvm/vlapic.h
index 4656293..48ab3a6 100644
--- a/xen/include/asm-x86/hvm/vlapic.h
+++ b/xen/include/asm-x86/hvm/vlapic.h
@@ -132,6 +132,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, 
uint32_t icr_high);
 
 int vlapic_apicv_write(struct vcpu *v, unsigned int offset);
 
+void vlapic_reg_write(struct vcpu *v, unsigned int offset, uint32_t val);
+
+uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int offset);
+
 struct vlapic *vlapic_lowest_prio(
 struct domain *d, const struct vlapic *source,
 int short_hand, uint32_t dest, bool_t dest_mode);
-- 
1.9.1


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

[Xen-devel] [RFC PATCH 1/9] x86/HVM: Introduce struct hvm_pi_ops

[Suravee Suthikulpanit]

The current function pointers for managing hvm posted interrupt
can be used also by SVM AVIC. Therefore, this patch introduces the
struct hvm_pi_ops in the struct hvm_domain to hold them.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/vmx/vmx.c | 32 +--
 xen/include/asm-x86/hvm/domain.h   | 63 ++
 xen/include/asm-x86/hvm/hvm.h  |  4 +--
 xen/include/asm-x86/hvm/vmx/vmcs.h | 59 ---
 4 files changed, 81 insertions(+), 77 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2759e6f..8620697 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -204,12 +204,12 @@ void vmx_pi_hooks_assign(struct domain *d)
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
-ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
+ASSERT(!d->arch.hvm_domain.pi_ops.vcpu_block);
 
-d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
-d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
-d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
-d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
+d->arch.hvm_domain.pi_ops.vcpu_block = vmx_vcpu_block;
+d->arch.hvm_domain.pi_ops.pi_switch_from = vmx_pi_switch_from;
+d->arch.hvm_domain.pi_ops.pi_switch_to = vmx_pi_switch_to;
+d->arch.hvm_domain.pi_ops.pi_do_resume = vmx_pi_do_resume;
 }
 
 /* This function is called when pcidevs_lock is held */
@@ -218,12 +218,12 @@ void vmx_pi_hooks_deassign(struct domain *d)
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
-ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
+ASSERT(d->arch.hvm_domain.pi_ops.vcpu_block);
 
-d->arch.hvm_domain.vmx.vcpu_block = NULL;
-d->arch.hvm_domain.vmx.pi_switch_from = NULL;
-d->arch.hvm_domain.vmx.pi_switch_to = NULL;
-d->arch.hvm_domain.vmx.pi_do_resume = NULL;
+d->arch.hvm_domain.pi_ops.vcpu_block = NULL;
+d->arch.hvm_domain.pi_ops.pi_switch_from = NULL;
+d->arch.hvm_domain.pi_ops.pi_switch_to = NULL;
+d->arch.hvm_domain.pi_ops.pi_do_resume = NULL;
 }
 
 static int vmx_domain_initialise(struct domain *d)
@@ -901,8 +901,8 @@ static void vmx_ctxt_switch_from(struct vcpu *v)
 vmx_restore_host_msrs();
 vmx_save_dr(v);
 
-if ( v->domain->arch.hvm_domain.vmx.pi_switch_from )
-v->domain->arch.hvm_domain.vmx.pi_switch_from(v);
+if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_from )
+v->domain->arch.hvm_domain.pi_ops.pi_switch_from(v);
 }
 
 static void vmx_ctxt_switch_to(struct vcpu *v)
@@ -916,8 +916,8 @@ static void vmx_ctxt_switch_to(struct vcpu *v)
 vmx_restore_guest_msrs(v);
 vmx_restore_dr(v);
 
-if ( v->domain->arch.hvm_domain.vmx.pi_switch_to )
-v->domain->arch.hvm_domain.vmx.pi_switch_to(v);
+if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_to )
+v->domain->arch.hvm_domain.pi_ops.pi_switch_to(v);
 }
 
 
@@ -3914,8 +3914,8 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
 struct hvm_vcpu_asid *p_asid;
 bool_t need_flush;
 
-if ( curr->domain->arch.hvm_domain.vmx.pi_do_resume )
-curr->domain->arch.hvm_domain.vmx.pi_do_resume(curr);
+if ( curr->domain->arch.hvm_domain.pi_ops.pi_do_resume )
+curr->domain->arch.hvm_domain.pi_ops.pi_do_resume(curr);
 
 if ( !cpu_has_vmx_vpid )
 goto out;
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index f34d784..779927b 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -72,6 +72,67 @@ struct hvm_ioreq_server {
 bool_t bufioreq_atomic;
 };
 
+struct hvm_pi_ops {
+/*
+ * To handle posted interrupts correctly, we need to set the following
+ * state:
+ *
+ * * The PI notification vector (NV)
+ * * The PI notification destination processor (NDST)
+ * * The PI "suppress notification" bit (SN)
+ * * The vcpu pi "blocked" list
+ *
+ * If a VM is currently running, we want the PI delivered to the guest vcpu
+ * on the proper pcpu (NDST = v->processor, SN clear).
+ *
+ * If the vm is blocked, we want the PI delivered to Xen so that it can
+ * wake it up  (SN clear, NV = pi_wakeup_vector, vcpu on block list).
+ *
+ * If the VM is currently either preempted or offline (i.e., not running
+ * because of some reason other than blocking waiting for an interrupt),
+ * there's nothing Xen can do -- we want the interrupt pending bit set in
+ * the guest, but we don't want to bother Xen with an interrupt (SN clear).
+ *
+ * There's a brief window of time between vmx_intr_assist() and checking
+ * softirqs where if an interrupt comes in it may be lost; so we need Xen
+ * to get an interrupt and raise a softirq so that it will go through the
+ * vmx_intr_assist() path again (SN 

[Xen-devel] [RFC PATCH 4/9] x86/SVM: Modify VMCB fields to add AVIC support

[Suravee Suthikulpanit]

Introduce AVIC-related VMCB fields.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/include/asm-x86/hvm/svm/vmcb.h | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index bad2382..768e9fb 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -328,14 +328,15 @@ typedef union __packed
 struct 
 {
 u64 tpr:  8;
-u64 irq:  1;
+u64 irq:  1; /* disabled for avic */
 u64 rsvd0:7;
-u64 prio: 4;
-u64 ign_tpr:  1;
+u64 prio: 4; /* disabled for avic */
+u64 ign_tpr:  1; /* disabled for avic */
 u64 rsvd1:3;
 u64 intr_masking: 1;
-u64 rsvd2:7;
-u64 vector:   8;
+u64 rsvd2:6;
+u64 avic_enable:  1;
+u64 vector:   8; /* disabled for avic */
 u64 rsvd3:   24;
 } fields;
 } vintr_t;
@@ -394,7 +395,8 @@ typedef union __packed
 uint32_t cr2: 1;
 /* debugctlmsr, last{branch,int}{to,from}ip */
 uint32_t lbr: 1;
-uint32_t resv: 21;
+uint32_t avic: 1;
+uint32_t resv: 20;
 } fields;
 } vmcbcleanbits_t;
 
@@ -428,7 +430,8 @@ struct __packed vmcb_struct {
 u64 exitinfo2;  /* offset 0x80 */
 eventinj_t  exitintinfo;/* offset 0x88 */
 u64 _np_enable; /* offset 0x90 - cleanbit 4 */
-u64 res08[2];
+u64 avic_vapic_bar; /* offset 0x98 */
+u64 res08;  /* offset 0xA0 */
 eventinj_t  eventinj;   /* offset 0xA8 */
 u64 _h_cr3; /* offset 0xB0 - cleanbit 4 */
 lbrctrl_t lbr_control;  /* offset 0xB8 */
@@ -437,7 +440,11 @@ struct __packed vmcb_struct {
 u64 nextrip;/* offset 0xC8 */
 u8  guest_ins_len;  /* offset 0xD0 */
 u8  guest_ins[15];  /* offset 0xD1 */
-u64 res10a[100];/* offset 0xE0 pad to save area */
+u64 avic_bk_pg_pa;  /* offset 0xE0 */
+u64 res09a; /* offset 0xE8 */
+u64 avic_log_apic_id;   /* offset 0xF0 */
+u64 avic_phy_apic_id;   /* offset 0xF8 */
+u64 res09b[96]; /* offset 0x100 pad to save area */
 
 svm_segment_register_t es;  /* offset 1024 - cleanbit 8 */
 svm_segment_register_t cs;  /* cleanbit 8 */
-- 
1.9.1


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

[Xen-devel] [RFC PATCH 3/9] x86/HVM: Call vlapic_destroy after vcpu_destroy

[Suravee Suthikulpanit]

Since vlapic_init() is called before vcpu_initialise().
We should also follow the same order here.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/hvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7bad845..fb5bf6c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1606,10 +1606,10 @@ void hvm_vcpu_destroy(struct vcpu *v)
 tasklet_kill(>arch.hvm_vcpu.assert_evtchn_irq_tasklet);
 hvm_vcpu_cacheattr_destroy(v);
 
+hvm_funcs.vcpu_destroy(v);
+
 if ( is_hvm_vcpu(v) )
 vlapic_destroy(v);
-
-hvm_funcs.vcpu_destroy(v);
 }
 
 void hvm_vcpu_down(struct vcpu *v)
-- 
1.9.1


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

[Xen-devel] [RFC PATCH 5/9] x86/HVM/SVM: Add AVIC initialization code

[Suravee Suthikulpanit]

Introduce AVIC base initialization code. This includes:
* Setting up per-VM data structures.
* Setting up per-vCPU data structure.
* Initializing AVIC-related VMCB bit fields.

This patch also introduces a new Xen parameter (svm-avic),
which can be used to enable/disable AVIC support.
Currently, this svm-avic is disabled by default.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/Makefile  |   1 +
 xen/arch/x86/hvm/svm/avic.c| 217 +
 xen/arch/x86/hvm/svm/svm.c |  17 ++-
 xen/arch/x86/hvm/svm/vmcb.c|   3 +
 xen/include/asm-x86/hvm/svm/avic.h |  40 +++
 xen/include/asm-x86/hvm/svm/svm.h  |   2 +
 xen/include/asm-x86/hvm/svm/vmcb.h |  10 ++
 7 files changed, 289 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/hvm/svm/avic.c
 create mode 100644 xen/include/asm-x86/hvm/svm/avic.h

diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index 760d295..e0e4a59 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -1,4 +1,5 @@
 obj-y += asid.o
+obj-y += avic.o
 obj-y += emulate.o
 obj-bin-y += entry.o
 obj-y += intr.o
diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
new file mode 100644
index 000..70bac69
--- /dev/null
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -0,0 +1,217 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* NOTE: Current max index allowed for physical APIC ID table is 255 */
+#define AVIC_PHY_APIC_ID_MAX0xFF
+
+#define AVIC_DOORBELL   0xc001011b
+#define AVIC_HPA_MASK   ~((0xFFFULL << 52) || 0xFFF)
+#define AVIC_APIC_BAR_MASK  0xFF000ULL
+
+bool_t svm_avic = 0;
+boolean_param("svm-avic", svm_avic);
+
+static struct svm_avic_phy_ait_entry *
+avic_get_phy_ait_entry(struct vcpu *v, int index)
+{
+struct svm_avic_phy_ait_entry *avic_phy_ait;
+struct svm_domain *d = >domain->arch.hvm_domain.svm;
+
+if ( !d->avic_phy_ait_mfn )
+return NULL;
+
+/**
+* Note: APIC ID = 0xff is used for broadcast.
+*   APIC ID > 0xff is reserved.
+*/
+if ( index >= 0xff )
+return NULL;
+
+avic_phy_ait = mfn_to_virt(d->avic_phy_ait_mfn);
+
+return _phy_ait[index];
+}
+
+/***
+ * AVIC APIs
+ */
+int svm_avic_dom_init(struct domain *d)
+{
+int ret = 0;
+struct page_info *pg;
+unsigned long mfn;
+
+if ( !svm_avic )
+return 0;
+
+/**
+ * Note:
+ * AVIC hardware walks the nested page table to check permissions,
+ * but does not use the SPA address specified in the leaf page
+ * table entry since it uses  address in the AVIC_BACKING_PAGE pointer
+ * field of the VMCB. Therefore, we set up a dummy page here _mfn(0).
+ */
+if ( !d->arch.hvm_domain.svm.avic_access_page_done )
+{
+set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
+   _mfn(0), PAGE_ORDER_4K,
+   p2m_get_hostp2m(d)->default_access);
+d->arch.hvm_domain.svm.avic_access_page_done = true;
+}
+
+/* Init AVIC log APIC ID table */
+pg = alloc_domheap_page(d, MEMF_no_owner);
+if ( !pg )
+{
+dprintk(XENLOG_ERR, "alloc AVIC logical APIC ID table error: %d\n",
+d->domain_id);
+ret = -ENOMEM;
+goto err_out;
+}
+mfn = page_to_mfn(pg);
+clear_domain_page(_mfn(mfn));
+d->arch.hvm_domain.svm.avic_log_ait_mfn = mfn;
+
+/* Init AVIC phy APIC ID table */
+pg = alloc_domheap_page(d, MEMF_no_owner);
+if ( !pg )
+{
+dprintk(XENLOG_ERR, "alloc AVIC physical APIC ID table error: %d\n",
+d->domain_id);
+ret = -ENOMEM;
+goto err_out;
+}
+mfn = page_to_mfn(pg);
+clear_domain_page(_mfn(mfn));
+d->arch.hvm_domain.svm.avic_phy_ait_mfn = mfn;
+
+return ret;
+err_out:
+svm_avic_dom_destroy(d);
+return ret;
+}
+
+void svm_avic_dom_destroy(struct domain *d)
+{
+if ( !svm_avic )
+return;
+
+if ( d->arch.hvm_domain.svm.avic_phy_ait_mfn )
+{
+
free_domheap_page(mfn_to_page(d->arch.hvm_domain.svm.avic_phy_ait_mfn));
+d->arch.hvm_domain.svm.avic_phy_ait_mfn = 0;
+}
+
+if ( d->arch.hvm_domain.svm.avic_log_ait_mfn )
+{
+
free_domheap_page(mfn_to_page(d->arch.hvm_domain.svm.avic_log_ait_mfn));
+d->arch.hvm_domain.svm.avic_log_ait_mfn = 0;
+}
+}
+
+/**
+ * Note: At this point, vlapic->regs_page is already initialized.
+ */
+int svm_avic_init_vcpu(struct vcpu *v)
+{
+struct vlapic *vlapic = vcpu_vlapic(v);
+struct arch_svm_struct *s = >arch.hvm_svm;
+
+if ( svm_avic )
+s->avic_bk_pg = vlapic->regs_page;
+return 0;
+}
+
+void svm_avic_destroy_vcpu(struct vcpu *v)
+{
+struct 

[Xen-devel] [RFC PATCH 6/9] x86/SVM: Add AVIC vmexit handlers

[Suravee Suthikulpanit]

AVIC introduces two #vmexit handlers:
  * VMEXIT_INCOMP_IPI
  * VMEXIT_DO_NOACCEL

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/avic.c| 279 +
 xen/arch/x86/hvm/svm/svm.c |   8 ++
 xen/include/asm-x86/hvm/svm/avic.h |   3 +
 xen/include/asm-x86/hvm/svm/vmcb.h |   2 +
 4 files changed, 292 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index 70bac69..90df181 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -18,6 +18,7 @@
 #define AVIC_DOORBELL   0xc001011b
 #define AVIC_HPA_MASK   ~((0xFFFULL << 52) || 0xFFF)
 #define AVIC_APIC_BAR_MASK  0xFF000ULL
+#define AVIC_UNACCEL_ACCESS_OFFSET_MASK0xFF0
 
 bool_t svm_avic = 0;
 boolean_param("svm-avic", svm_avic);
@@ -215,3 +216,281 @@ int svm_avic_init_vmcb(struct vcpu *v)
 
 return 0;
 }
+
+/***
+ * AVIC INCOMP IPI VMEXIT
+ */
+void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs)
+{
+struct vcpu *v = current;
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+u32 icrh = vmcb->exitinfo1 >> 32;
+u32 icrl = vmcb->exitinfo1;
+u32 id = vmcb->exitinfo2 >> 32;
+u32 index = vmcb->exitinfo2 && 0xFF;
+
+dprintk(XENLOG_DEBUG, "SVM: %s: cpu=%#x, vcpu=%#x, "
+   "icrh:icrl=%#010x:%08x, id=%u, index=%u\n",
+   __func__, v->processor, v->vcpu_id, icrh, icrl, id, index);
+
+switch ( id )
+{
+case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
+/*
+ * AVIC hardware handles the generation of
+ * IPIs when the specified Message Type is Fixed
+ * (also known as fixed delivery mode) and
+ * the Trigger Mode is edge-triggered. The hardware
+ * also supports self and broadcast delivery modes
+ * specified via the Destination Shorthand(DSH)
+ * field of the ICRL. Logical and physical APIC ID
+ * formats are supported. All other IPI types cause
+ * a #VMEXIT, which needs to emulated.
+ */
+vlapic_reg_write(v, APIC_ICR2, icrh);
+vlapic_reg_write(v, APIC_ICR, icrl);
+break;
+case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
+{
+/*
+ * At this point, we expect that the AVIC HW has already
+ * set the appropriate IRR bits on the valid target
+ * vcpus. So, we just need to kick the appropriate vcpu.
+ */
+struct vcpu *c;
+struct domain *d = v->domain;
+uint32_t dest = GET_xAPIC_DEST_FIELD(icrh);
+uint32_t short_hand = icrl & APIC_SHORT_MASK;
+bool_t dest_mode = !!(icrl & APIC_DEST_MASK);
+
+for_each_vcpu ( d, c )
+{
+if ( vlapic_match_dest(vcpu_vlapic(c), vcpu_vlapic(v),
+   short_hand, dest, dest_mode) )
+{
+vcpu_kick(c);
+break;
+}
+}
+break;
+}
+case AVIC_INCMP_IPI_ERR_INV_TARGET:
+dprintk(XENLOG_ERR,
+"SVM: %s: Invalid IPI target (icr=%#08x:%08x, idx=%u)\n",
+__func__, icrh, icrl, index);
+break;
+case AVIC_INCMP_IPI_ERR_INV_BK_PAGE:
+dprintk(XENLOG_ERR,
+"SVM: %s: Invalid bk page (icr=%#08x:%08x, idx=%u)\n",
+__func__, icrh, icrl, index);
+break;
+default:
+dprintk(XENLOG_ERR, "SVM: %s: Unknown IPI interception\n", __func__);
+}
+}
+
+/***
+ * AVIC NOACCEL VMEXIT
+ */
+#define GET_APIC_LOGICAL_ID(x)(((x) >> 24) & 0xFFu)
+
+static struct svm_avic_log_ait_entry *
+avic_get_logical_id_entry(struct vcpu *v, u32 ldr, bool flat)
+{
+int index;
+struct svm_avic_log_ait_entry *avic_log_ait;
+struct svm_domain *d = >domain->arch.hvm_domain.svm;
+int dlid = GET_APIC_LOGICAL_ID(ldr);
+
+if ( !dlid )
+return NULL;
+
+if ( flat )
+{
+index = ffs(dlid) - 1;
+if ( index > 7 )
+return NULL;
+}
+else
+{
+int cluster = (dlid & 0xf0) >> 4;
+int apic = ffs(dlid & 0x0f) - 1;
+
+if ((apic < 0) || (apic > 7) || (cluster >= 0xf))
+return NULL;
+index = (cluster << 2) + apic;
+}
+
+avic_log_ait = mfn_to_virt(d->avic_log_ait_mfn);
+
+return _log_ait[index];
+}
+
+static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr, bool valid)
+{
+bool flat;
+struct svm_avic_log_ait_entry *entry, new_entry;
+
+flat = *avic_get_bk_page_entry(v, APIC_DFR) == APIC_DFR_FLAT;
+entry = avic_get_logical_id_entry(v, ldr, flat);
+if (!entry)
+return -EINVAL;
+
+new_entry = *entry;
+smp_rmb();
+new_entry.guest_phy_apic_id = g_phy_id;
+new_entry.valid = valid;
+*entry = new_entry;
+smp_wmb();
+
+return 0;
+}
+
+static int 

[Xen-devel] [linux-4.1 baseline-only test] 67728: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67728 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67728/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 67638
 build-amd64-xsm   3 host-install(3) broken REGR. vs. 67638
 build-i386-libvirt3 host-install(3) broken REGR. vs. 67638
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 67638
 build-amd64   3 host-install(3) broken REGR. vs. 67638
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 67638
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 67638

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 

[Xen-devel] [PATCH v5 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dongli Zhang]

This patch implemented parts of TODO left in commit id
a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush
filtering in alloc_heap_pages()). It moved TLB-flush filtering out into
populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow
to create a guest with memory size of more than 100GB on host with 100+
cpus.

This patch introduced a "MEMF_no_tlbflush" bit to memflags to indicate
whether TLB-flush should be done in alloc_heap_pages or its caller
populate_physmap.  Once this bit is set in memflags, alloc_heap_pages will
ignore TLB-flush. To use this bit after vm is created might lead to
security issue, that is, this would make pages accessible to the guest B,
when guest A may still have a cached mapping to them.

Therefore, this patch also introduced a "creation_finished" field to struct
domain to indicate whether this domain has ever got unpaused by hypervisor.
MEMF_no_tlbflush can be set only during vm creation phase when
creation_finished is still false before this domain gets unpaused for the
first time.

Signed-off-by: Dongli Zhang 
---
Changed since v4:
  * Rename is_ever_unpaused to creation_finished.
  * Change bool_t to bool.
  * Polish comments.

Changed since v3:
  * Set the flag to true in domain_unpause_by_systemcontroller when
unpausing the guest domain for the first time.
  * Use true/false for all boot_t variables.
  * Add unlikely to optimize "if statement".
  * Correct comment style.

Changed since v2:
  * Limit this optimization to domain creation time.

---
 xen/common/domain.c |  8 
 xen/common/memory.c | 28 
 xen/common/page_alloc.c |  3 ++-
 xen/include/xen/mm.h|  2 ++
 xen/include/xen/sched.h |  6 ++
 5 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a8804e4..c170c69 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1004,6 +1004,14 @@ int domain_unpause_by_systemcontroller(struct domain *d)
 {
 int old, new, prev = d->controller_pause_count;
 
+/*
+ * We record this information here for populate_physmap to figure out
+ * that the domain has finished being created. In fact, we're only
+ * allowed to set the MEMF_no_tlbflush flag during VM creation.
+ */
+if ( unlikely(!d->creation_finished) )
+d->creation_finished = true;
+
 do
 {
 old = prev;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index cc0f69e..27d1f2a 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -141,6 +141,8 @@ static void populate_physmap(struct memop_args *a)
 unsigned int i, j;
 xen_pfn_t gpfn, mfn;
 struct domain *d = a->domain, *curr_d = current->domain;
+bool need_tlbflush = false;
+uint32_t tlbflush_timestamp = 0;
 
 if ( !guest_handle_subrange_okay(a->extent_list, a->nr_done,
  a->nr_extents-1) )
@@ -150,6 +152,17 @@ static void populate_physmap(struct memop_args *a)
 max_order(curr_d)) )
 return;
 
+/*
+ * With MEMF_no_tlbflush set, alloc_heap_pages() will ignore
+ * TLB-flushes. After VM creation, this is a security issue (it can
+ * make pages accessible to guest B, when guest A may still have a
+ * cached mapping to them). So we only do this only during domain
+ * creation, when the domain itself has not yet been unpaused for the
+ * first time.
+ */
+if ( unlikely(!d->creation_finished) )
+a->memflags |= MEMF_no_tlbflush;
+
 for ( i = a->nr_done; i < a->nr_extents; i++ )
 {
 if ( i != a->nr_done && hypercall_preempt_check() )
@@ -214,6 +227,19 @@ static void populate_physmap(struct memop_args *a)
 goto out;
 }
 
+if ( unlikely(a->memflags & MEMF_no_tlbflush) )
+{
+for ( j = 0; j < (1U << a->extent_order); j++ )
+{
+if ( accumulate_tlbflush(need_tlbflush, [j],
+ tlbflush_timestamp) )
+{
+need_tlbflush = true;
+tlbflush_timestamp = page[j].tlbflush_timestamp;
+}
+}
+}
+
 mfn = page_to_mfn(page);
 }
 
@@ -232,6 +258,8 @@ static void populate_physmap(struct memop_args *a)
 }
 
 out:
+if ( need_tlbflush )
+filtered_flush_tlb_mask(tlbflush_timestamp);
 a->nr_done = i;
 }
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 173c10d..a67f49b 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -827,7 +827,8 @@ static struct page_info *alloc_heap_pages(
 BUG_ON(pg[i].count_info != PGC_state_free);
 pg[i].count_info = PGC_state_inuse;
 
-if ( accumulate_tlbflush(need_tlbflush, [i],
+  

[Xen-devel] [PATCH v5 1/2] xen: replace tlbflush check and operation with inline functions

[Dongli Zhang]

This patch cleaned up the code by replacing complicated tlbflush check and
operation with inline functions. We should use those inline functions to
avoid the complicated tlbflush check and tlbflush operations when
implementing TODOs left in commit a902c12ee45fc9389eb8fe54eeddaf267a555c58
(More efficient TLB-flush filtering in alloc_heap_pages()).

"#include " is removed from xen/arch/x86/acpi/suspend.c to
avoid the compiling error after we include "" to
xen/include/xen/mm.h.

Signed-off-by: Dongli Zhang 
---
Changed since v4:
  * Wrap the filtered tlbflush mask operation as inline function (suggested
by Jan).
  * Remove asm/flushtlb.h from suspend.c to avoid compiling error.

Changed since v3:
  * Wrap the complicated tlbflush condition check as inline function
(suggested by Dario).

---
 xen/arch/x86/acpi/suspend.c |  1 -
 xen/common/page_alloc.c | 16 +++-
 xen/include/xen/mm.h| 25 +
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/acpi/suspend.c b/xen/arch/x86/acpi/suspend.c
index 1d8344c..d5c67ee 100644
--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 18ff6cf..173c10d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -827,10 +827,8 @@ static struct page_info *alloc_heap_pages(
 BUG_ON(pg[i].count_info != PGC_state_free);
 pg[i].count_info = PGC_state_inuse;
 
-if ( pg[i].u.free.need_tlbflush &&
- (pg[i].tlbflush_timestamp <= tlbflush_current_time()) &&
- (!need_tlbflush ||
-  (pg[i].tlbflush_timestamp > tlbflush_timestamp)) )
+if ( accumulate_tlbflush(need_tlbflush, [i],
+ tlbflush_timestamp) )
 {
 need_tlbflush = 1;
 tlbflush_timestamp = pg[i].tlbflush_timestamp;
@@ -849,15 +847,7 @@ static struct page_info *alloc_heap_pages(
 spin_unlock(_lock);
 
 if ( need_tlbflush )
-{
-cpumask_t mask = cpu_online_map;
-tlbflush_filter(mask, tlbflush_timestamp);
-if ( !cpumask_empty() )
-{
-perfc_incr(need_flush_tlb_flush);
-flush_tlb_mask();
-}
-}
+filtered_flush_tlb_mask(tlbflush_timestamp);
 
 return pg;
 }
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index f470e49..85848e3 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 TYPE_SAFE(unsigned long, mfn);
@@ -567,4 +568,28 @@ int prepare_ring_for_helper(struct domain *d, unsigned 
long gmfn,
 struct page_info **_page, void **_va);
 void destroy_ring_for_helper(void **_va, struct page_info *page);
 
+#include 
+
+static inline bool accumulate_tlbflush(bool need_tlbflush,
+   const struct page_info *page,
+   uint32_t tlbflush_timestamp)
+{
+return page->u.free.need_tlbflush &&
+   page->tlbflush_timestamp <= tlbflush_current_time() &&
+   (!need_tlbflush ||
+page->tlbflush_timestamp > tlbflush_timestamp);
+}
+
+static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
+{
+cpumask_t mask = cpu_online_map;
+
+tlbflush_filter(mask, tlbflush_timestamp);
+if ( !cpumask_empty() )
+{
+perfc_incr(need_flush_tlb_flush);
+flush_tlb_mask();
+}
+}
+
 #endif /* __XEN_MM_H__ */
-- 
1.9.1


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

Re: [Xen-devel] [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Miller]

From: Vitaly Kuznetsov 
Date: Fri, 16 Sep 2016 12:59:14 +0200

> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, struct 
> net_device *dev)
>   offset = offset_in_page(skb->data);
>   len = skb_headlen(skb);
>  
> + /* The first req should be at least ETH_HLEN size or the packet will be
> +  * dropped by netback.
> +  */
> + if (unlikely(PAGE_SIZE - offset < ETH_HLEN)) {
> + nskb = skb_copy(skb, GFP_ATOMIC);
> + if (!nskb)
> + goto drop;
> + dev_kfree_skb_any(skb);
> + skb = nskb;
> + page = virt_to_page(skb->data);
> + offset = offset_in_page(skb->data);
> + }
> +
>   spin_lock_irqsave(>tx_lock, flags);

I think you also have to recalculate 'len' in this case too, as
skb_headlen() will definitely be different for nskb.

In fact, I can't see how this code can work properly without that fix.

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

[Xen-devel] [RFC 4/5] xen/arm: move vpidr from arch_domain to arch_vcpu

[van . freenix]

From: Peng Fan 

Move vpidr from arch_domain to arch_vcpu.

In order to support Big.Little, Big CPUs and Little CPUs are
assigned to different cpupools.

when a new domain is to be created with cpupool specificed, the domain
is first assigned to cpupool0 and then the domain moved from cpupool0
to the specified cpupool.

In domain creation process arch_domain_create, vpidr is initialized
with boot_cpu_data.midr.bits. But Big cpupool and Little cpupool have
different midr, the guest vcpu midr should use the midr info from
cpupool which the domain runs in.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/domain.c| 9 +
 xen/arch/arm/traps.c | 2 +-
 xen/include/asm-arm/domain.h | 9 ++---
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 20bb2ba..934c112 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -150,7 +151,7 @@ static void ctxt_switch_to(struct vcpu *n)
 
 p2m_restore_state(n);
 
-WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
+WRITE_SYSREG32(n->arch.vpidr, VPIDR_EL2);
 WRITE_SYSREG(n->arch.vmpidr, VMPIDR_EL2);
 
 /* VGIC */
@@ -521,6 +522,9 @@ int vcpu_initialise(struct vcpu *v)
 
 v->arch.actlr = READ_SYSREG32(ACTLR_EL1);
 
+/* The virtual ID matches the physical id of the cpu in the cpupool */
+v->arch.vpidr = v->domain->cpupool->info.midr;
+
 processor_vcpu_initialise(v);
 
 if ( (rc = vcpu_vgic_init(v)) != 0 )
@@ -562,9 +566,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
 goto fail;
 
-/* Default the virtual ID to match the physical */
-d->arch.vpidr = boot_cpu_data.midr.bits;
-
 clear_page(d->shared_info);
 share_xen_page_with_guest(
 virt_to_page(d->shared_info), d, XENSHARE_writable);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 683bcb2..c0ad97e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1975,7 +1975,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const 
union hsr hsr)
  *  - Variant and Revision bits match MDIR
  */
 val = (1 << 24) | (5 << 16);
-val |= ((d->arch.vpidr >> 20) & 0xf) | (d->arch.vpidr & 0xf);
+val |= ((d->vcpu[0]->arch.vpidr >> 20) & 0xf) | 
(d->vcpu[0]->arch.vpidr & 0xf);
 set_user_reg(regs, regidx, val);
 
 break;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 9452fcd..b998c6d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -63,9 +63,6 @@ struct arch_domain
 RELMEM_done,
 } relmem;
 
-/* Virtual CPUID */
-uint32_t vpidr;
-
 struct {
 uint64_t offset;
 } phys_timer_base;
@@ -173,6 +170,12 @@ struct arch_vcpu
 uint32_t esr;
 #endif
 
+/*
+ * Holds the value of the Virtualization Processor ID.
+ * This is the value returned by Non-secure EL1 reads of MIDR_EL1.
+ */
+uint32_t vpidr;
+
 uint32_t ifsr; /* 32-bit guests only */
 uint32_t afsr0, afsr1;
 
-- 
2.6.6


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

[Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[van . freenix]

From: Peng Fan 

This patchset is to support XEN run on big.little SoC.
The idea of the patch is from
"https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00465.html;

There are some changes to cpupool and add x86 stub functions to avoid build
break. Sending The RFC patchset out is to request for comments to see whether
this implementation is acceptable or not. Patchset have been tested based on
xen-4.8 unstable on NXP i.MX8.

I use Big/Little CPU and cpupool to explain the idea.
A pool contains Big CPUs is called Big Pool.
A pool contains Little CPUs is called Little Pool.
If a pool does not contains any physical cpus, Little CPUs or Big CPUs
can be added to the cpupool. But the cpupool can not contain both Little
and Big CPUs. The CPUs in a cpupool must have the same cpu type(midr value for 
ARM).
CPUs can not be added to the cpupool which contains cpus that have different 
cpu type.
Little CPUs can not be moved to Big Pool if there are Big CPUs in Big Pool,
and versa. Domain in Big Pool can not be migrated to Little Pool, and versa.
When XEN tries to bringup all the CPUs, only add CPUs with the same cpu 
type(same midr value)
into cpupool0.

Thinking an SoC with 4 A53(cpu[0-3]) + 2 A72(cpu[4-5]), cpu0 is the first one
that boots up. When XEN tries to bringup secondary CPUs, add cpu[0-3] to
cpupool0 and leave cpu[4-5] not in any cpupool. Then when Dom0 boots up,
`xl cpupool-list -c` will show cpu[0-3] in Pool-0.

Then use the following script to create a new cpupool and add cpu[4-5] to
the cpupool.
 #xl cpupool-create name=\"Pool-A72\" sched=\"credit2\"
 #xl cpupool-cpu-add Pool-A72 4
 #xl cpupool-cpu-add Pool-A72 5
 #xl create -d /root/xen/domu-test pool=\"Pool-A72\"
Now `xl cpupool-list -c` shows:
NameCPU list
Pool-0  0,1,2,3 
Pool-A724,5

`xl cpupool-list` shows:
Name   CPUs   Sched Active   Domain count
Pool-0   4credit   y  1
Pool-A72 2   credit2   y  1

`xl cpupool-cpu-remove Pool-A72 4`, then `xl cpupool-cpu-add Pool-0 4`
not success, because Pool-0 contains A53 CPUs, but CPU4 is an A72 CPU.

`xl cpupool-migrate DomU Pool-0` will also fail, because DomU is created
in Pool-A72 with A72 vcpu, while Pool-0 have A53 physical cpus.

Patch 1/5:
use "cpumask_weight(cpupool0->cpu_valid);" to replace "num_online_cpus()",
because num_online_cpus() counts all the online CPUs, but now we only
need Big or Little CPUs.

Patch 2/5:
Introduce cpupool_arch_info. To ARM SoC, need to add midr info to the cpupool.
The info will be used in patch [3,4,5]/5.

Patch 3/5:
Need to check whether it is ok to add a physical cpu to a cpupool,
When the cpupool does not contain any physical cpus, it is ok
to add a cpu to the cpupool without care the cpu type.
Need to check whether it is ok to move a domain to another cpupool.

Patch 4/5:
move vpidr from arch_domain to arch_vcpu.
The vpidr in arch_domain is initialized in arch_domain_create,
at this time, the domain is still in cpupool0, not moved the specified
cpupool. We need to initialize vpidr later. But at the late stage,
no method to initialize vpidr in arch_domain, so I move it to
arch_vcpu.

Patch 5/5:
This is to check whether it is ok to move a domain to another cpupool.

Peng Fan (5):
  xen/arm: domain_build: setting opt_dom0_max_vcpus according to
cpupool0 info
  xen: cpupool: introduce cpupool_arch_info
  xen: cpupool: add arch cpupool hook
  xen/arm: move vpidr from arch_domain to arch_vcpu
  xen/arm: cpupool: implement arch_domain_cpupool_compatible

 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/cpupool.c| 60 +++
 xen/arch/arm/domain.c |  9 ---
 xen/arch/arm/domain_build.c   |  3 ++-
 xen/arch/arm/traps.c  |  2 +-
 xen/arch/x86/cpu/Makefile |  1 +
 xen/arch/x86/cpu/cpupool.c| 30 ++
 xen/common/cpupool.c  | 30 ++
 xen/include/asm-arm/cpupool.h | 16 
 xen/include/asm-arm/domain.h  |  9 ---
 xen/include/asm-x86/cpupool.h | 16 
 xen/include/xen/sched-if.h|  5 
 12 files changed, 173 insertions(+), 9 deletions(-)
 create mode 100644 xen/arch/arm/cpupool.c
 create mode 100644 xen/arch/x86/cpu/cpupool.c
 create mode 100644 xen/include/asm-arm/cpupool.h
 create mode 100644 xen/include/asm-x86/cpupool.h

-- 
2.6.6


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

[Xen-devel] [RFC 5/5] xen/arm: cpupool: implement arch_domain_cpupool_compatible

[van . freenix]

From: Peng Fan 

When migrating domain between different cpupools, need to check
whether the domain is compatible with the cpupool.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/cpupool.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/cpupool.c b/xen/arch/arm/cpupool.c
index 74a5ef3..6c1c092 100644
--- a/xen/arch/arm/cpupool.c
+++ b/xen/arch/arm/cpupool.c
@@ -41,5 +41,20 @@ int arch_cpupool_cpu_add(struct cpupool *c, unsigned int cpu)
 
 bool_t arch_domain_cpupool_compatible(struct domain *d, struct cpupool *c)
 {
-return true;
+if ( !d->vcpu || !d->vcpu[0] )
+{
+/*
+ * We are in process of domain creation, vcpu not constructed or
+ * initialiszed, ok to move domain from cpupool0 to other pool
+ */
+return true;
+}
+else if ( d->vcpu[0] )
+{
+return !!( d->vcpu[0]->arch.vpidr == c->info.midr );
+}
+else
+{
+return false;
+}
 }
-- 
2.6.6


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

[Xen-devel] [RFC 1/5] xen/arm: domain_build: setting opt_dom0_max_vcpus according to cpupool0 info

[van . freenix]

From: Peng Fan 

Setting opt_dom0_max_vcpus according to cpu_valid in cpupool0.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/domain_build.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..d171c39 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -59,7 +60,7 @@ custom_param("dom0_mem", parse_dom0_mem);
 struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 {
 if ( opt_dom0_max_vcpus == 0 )
-opt_dom0_max_vcpus = num_online_cpus();
+opt_dom0_max_vcpus = cpumask_weight(cpupool0->cpu_valid);
 if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
 opt_dom0_max_vcpus = MAX_VIRT_CPUS;
 
-- 
2.6.6


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

[Xen-devel] [RFC 3/5] xen: cpupool: add arch cpupool hook

[van . freenix]

From: Peng Fan 

Introduce arch_cpupool_create, arch_cpupool_cpu_add,
and arch_domain_cpupool_compatible.

To X86, nothing to do, just add an empty stub functions.

To ARM, arch_cpupool_create initialize midr with value -1;
arch_cpupool_cpu_add, if there is cpu in the cpupool or the cpu
is the first one that will be added to the cpupool, assign cpu
midr to cpupool midr. If the midr already initialzed and there is
valid cpus in the pool, check whether the midr of cpu and cpupool
is compatbile or not; arch_domain_cpupool_compatible is to check
whether the domain is ok to be moved into the cpupool.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Juergen Gross 
Cc: Dario Faggioli 
---
 xen/arch/arm/Makefile  |  1 +
 xen/arch/arm/cpupool.c | 45 +
 xen/arch/x86/cpu/Makefile  |  1 +
 xen/arch/x86/cpu/cpupool.c | 30 ++
 xen/common/cpupool.c   | 30 ++
 xen/include/xen/sched-if.h |  3 +++
 6 files changed, 110 insertions(+)
 create mode 100644 xen/arch/arm/cpupool.c
 create mode 100644 xen/arch/x86/cpu/cpupool.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 23aaf52..1b72f66 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -9,6 +9,7 @@ obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpuerrata.o
 obj-y += cpufeature.o
+obj-y += cpupool.o
 obj-y += decode.o
 obj-y += device.o
 obj-y += domain.o
diff --git a/xen/arch/arm/cpupool.c b/xen/arch/arm/cpupool.c
new file mode 100644
index 000..74a5ef3
--- /dev/null
+++ b/xen/arch/arm/cpupool.c
@@ -0,0 +1,45 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+int arch_cpupool_create(struct cpupool *c)
+{
+c->info.midr = -1;
+
+return 0;
+}
+
+int arch_cpupool_cpu_add(struct cpupool *c, unsigned int cpu)
+{
+if (( c->info.midr == -1 ) || ( cpumask_weight(c->cpu_valid) == 0 ))
+{
+c->info.midr = cpu_data[cpu].midr.bits;
+
+return 0;
+}
+else if (( c->info.midr == cpu_data[cpu].midr.bits ))
+{
+return 0;
+}
+else
+{
+return -EINVAL;
+}
+}
+
+bool_t arch_domain_cpupool_compatible(struct domain *d, struct cpupool *c)
+{
+return true;
+}
diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 74f23ae..0d3036e 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -4,6 +4,7 @@ subdir-y += mtrr
 obj-y += amd.o
 obj-y += centaur.o
 obj-y += common.o
+obj-y += cpupool.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
diff --git a/xen/arch/x86/cpu/cpupool.c b/xen/arch/x86/cpu/cpupool.c
new file mode 100644
index 000..d897a1f
--- /dev/null
+++ b/xen/arch/x86/cpu/cpupool.c
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+int arch_cpupool_create(struct cpupool *c)
+{
+return 0;
+}
+
+int arch_cpupool_cpu_add(struct cpupool *c, unsigned int cpu)
+{
+return 0;
+}
+
+bool_t arch_domain_cpupool_compatible(struct domain *d, struct cpupool *c)
+{
+return true;
+}
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 9998394..798322d 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -134,11 +134,20 @@ static struct cpupool *cpupool_create(
 struct cpupool *c;
 struct cpupool **q;
 int last = 0;
+int ret;
 
 *perr = -ENOMEM;
 if ( (c = alloc_cpupool_struct()) == NULL )
 return NULL;
 
+ret = arch_cpupool_create(c);
+if ( ret )
+{
+*perr = ret;
+free_cpupool_struct(c);
+return NULL;
+}
+
 /* One reference for caller, one reference for cpupool_destroy(). */
 atomic_set(>refcnt, 2);
 
@@ -498,6 +507,8 @@ static int cpupool_cpu_add(unsigned int cpu)
 {

[Xen-devel] [RFC 2/5] xen: cpupool: introduce cpupool_arch_info

[van . freenix]

From: Peng Fan 

Intrdouce cpupool_arch_info.
To ARM, add a 'midr' entry to hold the MIDR info of the cpupool.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/include/asm-arm/cpupool.h | 16 
 xen/include/asm-x86/cpupool.h | 16 
 xen/include/xen/sched-if.h|  2 ++
 3 files changed, 34 insertions(+)
 create mode 100644 xen/include/asm-arm/cpupool.h
 create mode 100644 xen/include/asm-x86/cpupool.h

diff --git a/xen/include/asm-arm/cpupool.h b/xen/include/asm-arm/cpupool.h
new file mode 100644
index 000..f450199
--- /dev/null
+++ b/xen/include/asm-arm/cpupool.h
@@ -0,0 +1,16 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+struct cpupool_arch_info
+{
+uint32_t midr; /* Hold the MIDR info of the pool */
+};
diff --git a/xen/include/asm-x86/cpupool.h b/xen/include/asm-x86/cpupool.h
new file mode 100644
index 000..3251709
--- /dev/null
+++ b/xen/include/asm-x86/cpupool.h
@@ -0,0 +1,16 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+struct cpupool_arch_info
+{
+/* Nothing now.. */
+};
diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h
index bc0e794..eb52ac7 100644
--- a/xen/include/xen/sched-if.h
+++ b/xen/include/xen/sched-if.h
@@ -8,6 +8,7 @@
 #ifndef __XEN_SCHED_IF_H__
 #define __XEN_SCHED_IF_H__
 
+#include 
 #include 
 
 /* A global pointer to the initial cpupool (POOL0). */
@@ -186,6 +187,7 @@ struct cpupool
 unsigned int n_dom;
 struct scheduler *sched;
 atomic_t refcnt;
+struct cpupool_arch_info info;
 };
 
 #define cpupool_online_cpumask(_pool) \
-- 
2.6.6


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

Re: [Xen-devel] [edk2] edk2 compile error

[Chen, Farrah]

FYI.

Thanks,
Fan Chen

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Sunday, September 18, 2016 11:45 PM
To: Chen, Farrah 
Cc: edk2-de...@ml01.01.org; xen-devel@lists.xen.org
Subject: Re: [edk2] edk2 compile error


> On Sep 17, 2016, at 8:38 PM, Chen, Farrah  wrote:
> 
> Hi,
> 
> When I compile xen with the latest commit in RHEL 6.7, it failed when make 
> tools. Errors showed when running edk2 build for OvmfPkgX64.
> Bisected and this error occurred from commit 
> 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2.
> 
> commit 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2
> Author: Wei Liu >
> Date:   Tue Sep 6 12:54:47 2016 +0100
> 
>Config.mk: update OVMF commit
> 
> Signed-off-by: Wei Liu wei.l...@citrix.com
> 
> 
> We have updated OVMF to the latest master and cleaned everything before 
> rebuilding.
> 
> 
> 
> Steps:
> 
> make clean
> 
> make xen -j8
> 
> ./configure --enable-ovmf
> 
> make tools -j8
> 
> Then the error occurred.
> 
> 
> 
> 
> 
> I also tried:
> 
> git clone https://github.com/tianocore/edk2.git
> 
> cd edk2
> 
> OvmfPkg/build.sh -a X64 -b DEBUG -n 4
> The same error occurred.
> .
> 
> log:
> ..
> Running edk2 build for OvmfPkgX64
> ..
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315:
>  error: invalid combination of opcode and operands

Can you attach a copy of the failing ExceptionHandlerAsm.iii as it is the 
output of the preprocessor. 

Thanks,

Andrew Fish

> make[7]: Leaving directory 
> `/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib'
> make[7]: *** 
> [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj]
>  Error 1
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib]
> 
> 
> build.py...
> : error F002: Failed to build module
>
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>  [X64, GCC44, DEBUG]
> 
> - Failed -
> 
> 
> Thanks,
> Fan Chen
> 
> 
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



ExceptionHandlerAsm.iii
Description: ExceptionHandlerAsm.iii
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PC8 Residency on Broadwell hardware

[Nakajima, Jun]

> On Sep 13, 2016, at 9:10 AM, Nakajima, Jun  wrote:
> 
> 
>> On Sep 13, 2016, at 2:05 AM, Andrew Cooper  wrote:
>> 
>> On 13/09/16 08:51, Jan Beulich wrote:
>> On 12.09.16 at 19:28,  wrote:
>>> Please try to get quoting right - your response was rather hard to
>>> follow.
>>> 
 On Sep 12, 2016, at 2:00 AM, Jan Beulich 
 > wrote:
 
 On 12.09.16 at 10:47, 
 > wrote:
 c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of
 MSRs read by Xeon Broadwell hardware (specifically, model 79 / 0x47).
>>> I think this was misleading: 79 == 0x4f. Andrew, can you confirm in
>>> your case please?
>> 
>> Very sorry for the confusion.  Yes, I was talking about model 0x4f.
>> 
 Rereading the manual, it does indeed indicate that this MSR is available.
 
 However, experimentally it is not.  All Broadwell hardware XenServer has
 (both SDPs and production systems) reliably take a #GP fault when trying
 to read this MSR.  Haswell hardware appears fine (and indeed, was
 reading that MSR before).
 
 Where did you find the info? I think you are talking about 
 MSR_PKG_C8_RESIDENCY (630H).
>>> Yes.
>>> 
 The SDM says (35.13):
 
 "Processors with signatures 06_3DH and 06_47H support the MSR interfaces 
 listed in Table 35-18, Table 35-19, Table 35-20, Table 35-23, Table 35-27, 
 Table 35-28, Table 35-32, and Table 35-33.”
>>> Model 0x4f is what we're talking about, and table 35-36 has the information
>>> on MSR_PKG_C8_RESIDENCY (630H).
>> 
>> Correct.
>> 
>> ~Andrew
> 
> OK. We are taking a look at that now. Thanks for the report.
> 

We’ll remove the following MSRs from the table 35-36 in the next release: 
MSR_PKG_C8_RESIDENCY, MSR_PKG_C9_RESIDENCY and MSR_PKG_C10_RESIDENCY

Thank you for reporting this.
---
Jun
Intel Open Source Technology Center
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.1 test] 101004: tolerable FAIL - PUSHED

[osstest service owner]

flight 101004 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101004/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  11 guest-start  fail in 101001 pass in 101004
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail pass in 101001
 test-amd64-amd64-xl  19 guest-start/debian.repeat  fail pass in 101001
 test-amd64-amd64-libvirt-xsm 17 guest-start/debian.repeat  fail pass in 101001

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 100753
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat   fail like 100753
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 100753
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail  like 100753
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100753
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100753
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 100753
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100753
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100753
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100753

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 101001 never 
pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore  fail in 101001 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf
baseline version:
 linux3b60b86aec06fbae1142ccc4e55b39b529ae2a25

Last test of basis   100753  2016-09-05 06:44:50 Z   13 days
Testing same since   101001  2016-09-18 07:47:34 Z0 days2 attempts


People who touched revisions under test:
  Al Viro 
  Alan Stern 
  Aleksandr Makarov 
  Alexey Khoroshilov 
  Borislav Petkov 
  Brian Foster 
  Dave Chinner 
  Dave Chinner 
  Emanuel Czirai 

[Xen-devel] [linux-3.18 baseline-only test] 67727: trouble: blocked/broken/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67727 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67727/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   3 host-install(3) broken REGR. vs. 67643
 build-amd64   3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-xl   3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-xl-credit2   3 host-install(3) broken REGR. vs. 67643
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-xl-multivcpu  3 host-install(3)broken REGR. vs. 67643
 test-armhf-armhf-xl-midway3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-xl-vhd   3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-xl-xsm   3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-libvirt  3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)   broken REGR. vs. 67643
 test-armhf-armhf-libvirt-raw  3 host-install(3) broken REGR. vs. 67643
 test-armhf-armhf-libvirt-xsm  3 host-install(3) broken REGR. vs. 67643

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3) broken REGR. vs. 67643

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  

Re: [Xen-devel] [edk2] edk2 compile error

[Andrew Fish]

> On Sep 17, 2016, at 8:38 PM, Chen, Farrah  wrote:
> 
> Hi,
> 
> When I compile xen with the latest commit in RHEL 6.7, it failed when make 
> tools. Errors showed when running edk2 build for OvmfPkgX64.
> Bisected and this error occurred from commit 
> 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2.
> 
> commit 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2
> Author: Wei Liu >
> Date:   Tue Sep 6 12:54:47 2016 +0100
> 
>Config.mk: update OVMF commit
> 
> Signed-off-by: Wei Liu wei.l...@citrix.com
> 
> 
> We have updated OVMF to the latest master and cleaned everything before 
> rebuilding.
> 
> 
> 
> Steps:
> 
> make clean
> 
> make xen -j8
> 
> ./configure --enable-ovmf
> 
> make tools -j8
> 
> Then the error occurred.
> 
> 
> 
> 
> 
> I also tried:
> 
> git clone https://github.com/tianocore/edk2.git
> 
> cd edk2
> 
> OvmfPkg/build.sh -a X64 -b DEBUG -n 4
> The same error occurred.
> .
> 
> log:
> ..
> Running edk2 build for OvmfPkgX64
> ..
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315:
>  error: invalid combination of opcode and operands

Can you attach a copy of the failing ExceptionHandlerAsm.iii as it is the 
output of the preprocessor. 

Thanks,

Andrew Fish

> make[7]: Leaving directory 
> `/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib'
> make[7]: *** 
> [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj]
>  Error 1
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib]
> 
> 
> build.py...
> : error F002: Failed to build module
>
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>  [X64, GCC44, DEBUG]
> 
> - Failed -
> 
> 
> Thanks,
> Fan Chen
> 
> 
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


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

Re: [Xen-devel] [PATCH 0/3] Enable L2 Cache Allocation Technology

[Meng Xu]

On Sat, Sep 17, 2016 at 10:34 PM, Yi Sun  wrote:
> On 16-09-17 11:31:54, Meng Xu wrote:
>> On Thu, Aug 25, 2016 at 1:21 AM, Yi Sun  wrote:
>> >
>> > Design document is below:
>> > ===
>> > % Intel L2 Cache Allocation Technology (L2 CAT) Feature
>> > % Revision 1.0
>> >
>> > \clearpage
>> >
>> > Hi all,
>> >
>> > We plan to bring a new PSR (Platform Shared Resource) feature called
>> > Intel L2 Cache Allocation Technology (L2 CAT) to Xen.
>> >
>> > This is the initial design of L2 CAT. It might be a little long and
>> > detailed, hope it doesn't matter.
>> >
>> > Besides the L2 CAT implementaion, we refactor the psr.c to make it more
>> > flexible to add new features and fulfill the principle, open for extension
>> > but closed for modification.
>> >
>> > Comments and suggestions are welcome :-)
>>
>>
>> I have some comments/questions. ;-)
>>
>>
> Thanks for your comments and questions! :)
>
>> >
>> >
>> > # Basics
>> >
>> >  
>> >  Status: **Tech Preview**
>> >
>> > Architecture(s): Intel x86
>> >
>> >Component(s): Hypervisor, toolstack
>> >
>> >Hardware: Atom codename Goldmont and beyond
>> >  
>> >
>> > # Overview
>> >
>> > L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
>> > CPU's shared L2 cache based on application priority or Class of Service
>> > (COS). Each CLOS is configured using capacity bitmasks (CBM) which
>> > represent cache capacity and indicate the degree of overlap and
>> > isolation between classes. Once L2 CAT is configured, the processor
>> > allows access to portions of L2 cache according to the established
>> > class of service (COS).
>>
>>
>>
>> The very earlier version of the design at [1] said, "In the initial
>> implementation, L2 CAT is shown up on Atom codename
>> Goldmont firstly and there is no platform support both L2 & L3 CAT so far."
>>
>> I'm wondering if there is any hardware supporting both L2 & L3 CAT now.
>>
>> [1]http://www.gossamer-threads.com/lists/xen/devel/431142
>>
>>
> Per my info, CURRENT HWs does not support both L2 and L3. But from SW view,
> we cannot limit this. If both features are enabled in the future HW, SW
> should be able to support it.

OK. I'm not sure if this is the best way to do it. Since the hw will
be manufactured by Intel, I guess you guys know what the future HW
will be. ;-)

Actually, the Atom processor that support L2 CAT is similar to the
Broadwell processor in the sense that the CAT is only for the
Last-Level Cache.
I'm looking forward to the L2 CAT in the processor that has three
level cache. ;-)

>
>> >
>> >
>> > # Technical information
>> >
>> > L2 CAT is a member of Intel PSR features and part of CAT, it shares
>> > some base PSR infrastructure in Xen.
>> >
>> > ## Hardware perspective
>> >
>> > L2 CAT defines a new range MSRs to assign different L2 cache access
>> > patterns which are known as CBMs (Capacity BitMask), each CBM is
>> > associated with a COS.
>> >
>> > ```
>> >
>> > +++
>> >IA32_PQR_ASSOC   | MSR (per socket)   |Address |
>> >  ++---+---+ +++
>> >  ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
>> >  ++---+---+ +++
>> > └-> | ...|  ...   |
>> > +++
>> > | IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
>> > +++
>> > ```
>> >
>> > When context switch happens, the COS of VCPU is written to per-thread
>> > MSR `IA32_PQR_ASSOC`, and then hardware enforces L2 cache allocation
>> > according to the corresponding CBM.
>> >
>> > ## The relationship between L2 CAT and L3 CAT/CDP
>> >
>> > L2 CAT is independent of L3 CAT/CDP, which means L2 CAT would be enabled
>> > while L3 CAT/CDP is disabled, or L2 CAT and L3 CAT/CDP are all enabled.
>>
>> This sentence indicates that both L2 and L3 CAT can be enabled at the same 
>> time.
>> How can I know which CPU supports both L2 and L3 CAT?
>> Is the support architectural or just on several types of CPUs?
>> IMHO, it will be good to provide a reference about the type of CPUs
>> that supports L2 only, and that both L2 and L3.
>>
> Like above comment, no HWs support both L2 and L3 SO FAR but we should not
> limit this in SW. By CPUID tool or HW spec, you should know which feature
> is enabled on CPU.
>
>> >
>> > L2 CAT uses a new range CBMs from 0xD10 ~ 0xD10+n (n<64), following by
>> > the L3 CAT/CDP CBMs, and supports setting different L2 cache accessing
>> > patterns 

[Xen-devel] [linux-4.1 test] 101001: regressions - FAIL

[osstest service owner]

flight 101001 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101001/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  11 guest-start  fail REGR. vs. 100753

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 100753
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat   fail like 100753
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 100753
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail  like 100753
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100753
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100753
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100753
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100753
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100753

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf
baseline version:
 linux3b60b86aec06fbae1142ccc4e55b39b529ae2a25

Last test of basis   100753  2016-09-05 06:44:50 Z   13 days
Testing same since   101001  2016-09-18 07:47:34 Z0 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alan Stern 
  Aleksandr Makarov 
  Alexey Khoroshilov 
  Borislav Petkov 
  Brian Foster 
  Dave Chinner 
  Dave Chinner 
  Emanuel Czirai 
  Eric Biggers 
  Greg Kroah-Hartman 
  Ian Abbott 
  Jimi Damon 
  Johan Hovold 
  Jonathan Cameron 
  Konstantin Khlebnikov 
  Li Jun 
  Linus Torvalds 
  Linus Walleij 
  Mike Snitzer 
  Miklos Szeredi 

[Xen-devel] [linux-3.18 test] 101000: tolerable FAIL - PUSHED

[osstest service owner]

flight 101000 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101000/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100758
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100758
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100758

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linuxa8e202812b52b88e2a33d52687b3b0260706231a
baseline version:
 linuxe9e1b43e9f912ee8aad24534584a6257d2b43aba

Last test of basis   100758  2016-09-05 12:17:55 Z   13 days
Testing same since   101000  2016-09-18 07:47:20 Z0 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alan Stern 
  Aleksandr Makarov 
  Alexey Khoroshilov 
  Borislav Petkov 
  Dave Chinner 
  Dave Chinner 
  Emanuel Czirai 
  Eric Biggers 
  Greg Kroah-Hartman 
  Ian Abbott 
  Johan Hovold 
  Jonathan Cameron 
  Linus Torvalds 
  Linus Walleij 
  Mike Snitzer 
  Miklos Szeredi 
  Mikulas Patocka 
  Sasha Levin 
  Steven Rostedt 
  Tejun Heo 
  Theodore Ts'o 
  Thomas Gleixner 
  Trond Myklebust 
  Vittorio Zecca 
  Zefan Li 

jobs:
 

[Xen-devel] [xen-unstable-coverity test] 101002: all pass - PUSHED

[osstest service owner]

flight 101002 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101002/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8
baseline version:
 xen  773522000cc17f6f4323a4d97423790138ea98f2

Last test of basis   100952  2016-09-14 09:18:52 Z4 days
Testing same since   101002  2016-09-18 09:19:47 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Peng Fan 
  Peng Fan 
  Stefano Stabellini 
  Wei Liu 

jobs:
 coverity-amd64   pass



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

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=6559a686ae77bca2539d826120c9f3bd0d75cdf8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push 
xen-unstable-coverity 6559a686ae77bca2539d826120c9f3bd0d75cdf8
+ branch=xen-unstable-coverity
+ revision=6559a686ae77bca2539d826120c9f3bd0d75cdf8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' x6559a686ae77bca2539d826120c9f3bd0d75cdf8 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

[Xen-devel] [libvirt test] 100999: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  706b5b627719e95a33606c463bc83c841c7b5b0e
baseline version:
 libvirt  4a457adda649447a7873f48bf71c5139bc6404d2

Last test of basis   100962  2016-09-15 04:22:11 Z3 days
Failing since100980  2016-09-16 04:31:01 Z2 days3 attempts
Testing same since   100995  2016-09-17 04:21:26 Z1 days2 attempts


People who touched revisions under test:
  Jason Miesionczek 
  Laszlo Ersek 
  Martin Kletzander 
  Michal Privoznik 
  Shivaprasad G Bhat 
  Tomáš Ryšavý 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=libvirt
+ revision=706b5b627719e95a33606c463bc83c841c7b5b0e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Wu, Feng]

Hi Dario,

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, September 14, 2016 10:52 PM
> To: Wu, Feng ; Jan Beulich 
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org
> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> On Wed, 2016-09-14 at 02:23 +, Wu, Feng wrote:
> > Then I tried to implement the function like the following:
> >
> > /* This function is called when pcidevs_lock is held */
> > void vmx_pi_hooks_assign(struct domain *d)
> > {
> > if ( !iommu_intpost || !has_hvm_container_domain(d) )
> > return;
> >
> > ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> >
> > /*
> >  * We carefully handle the timing here:
> >  * - Install the context switch first
> >  * - Then set the NDST field
> >  * - Install the block and resume hooks in the end
> >  *
> >  * This can make sure the PI (especially the NDST feild) is
> >  * in proper state when we call vmx_vcpu_block().
> >  */
> > d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
> > d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> >
> > for_each_vcpu ( d, v )
> > {
> > unsigned int dest = cpu_physical_id(v->processor);
> > struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
> >
> > /* spot 1 */
> >
> > write_atomic(_desc->ndst,
> >  x2apic_enabled ? dest : MASK_INSR(dest,
> > PI_xAPIC_NDST_MASK));
> > }
> >
> > d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> > d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> > }
> >
> > However, I still think it is problematic. Consider the _spot 1_
> > above, we get
> > the pCPU of the vCPU and update the NDST, but the vCPU can be happily
> > rescheduled to another pCPU before updating the NDST. The problem is
> > that it is not safe to update NDST here, since vCPU can be scheduled
> > behind us at any time. And if this is the case, it is hard to safely
> > do this
> > without guarantee the vCPU is in a known state. Any further advice
> > on this? Thanks a lot!
> >
> So, I'm sorry if this is me missing or not remembering something... but
> I do remember that, at some point, in the early days of this series,
> there were concerns about the use of v->processor behind the back of
> the scheduler, i.e., without holding the proper scheduler related
> locks.
> 
> Pausing the domain was not even being remotely considered at the time,
> it (again, at least AFAICR) came up later for trying to address other
> issues.
> 
> No, the whole point of why that was not a problem in the first place is
> that what counts here is on the wait list of what pcpu the vcpu is put,
> not really where the vcpu is being or has been scheduled last. Of
> course it'd be better --and it would also be true most of the times--
> if there where a match, but that was not a correctness concern.
> 
> So why this is all of the sudden becoming one? Am I completely off with
> my recollection (or in general :-P)? Or what am I missing about the
> issue we are trying to address with this new bits of the work?

The issue discussed between Jan and me is that now we have four
PI hooks: vmx_pi_switch_from, vmx_pi_switch_to, vmx_vcpu_block,
and vmx_pi_do_resume. The previous assumption in vmx_vcpu_block()
is that when we are running this function, the NDST field should have
the same meaning with the current pCPU the vCPU is running on.
However, I found this is not true in some scenarios, such as,
vmx_pi_switch_to() hasn't been installed or executed before
vmx_vcpu_block() gets called, in which case, we may hit the ASSERT
in it. In previous version, I suggested we remove the ASSERT in
vmx_vcpu_block() and set NDST explicitly in it. But seems maintainer
doesn't like this idea. So currently we need to make sure the PI is
in proper state before the hooks get called, that is why I used pause/
unpause mechanism.

Thanks,
Feng

> 
> Thanks and Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [xen-unstable test] 100998: tolerable FAIL

[osstest service owner]

flight 100998 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100998/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm   6 xen-boot   fail pass in 100994

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100992
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100994
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100994
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100994
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100994
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100994

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 100994 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 100994 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8
baseline version:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8

Last test of basis   100998  2016-09-18 01:58:10 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17062 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern