date:20170815

In order to analyze PI blocking list operation frequence and obtain
the list length, add some relevant events to xentrace and some
associated code in xenalyze.

Signed-off-by: Chao Gao 
---
v5:
 - Put pi list operation under HW events and get rid of ASYNC stuff
 - generate scatterplot of pi list length on pcpus to be vivid to
 analyst.
v4:
 - trace part of Patch 1 in v3

---
 tools/xentrace/formats |   2 +
 tools/xentrace/xenalyze.c  | 116 +
 xen/arch/x86/hvm/vmx/vmx.c |  17 ++-
 xen/include/public/trace.h |   5 ++
 4 files changed, 138 insertions(+), 2 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index c1f584f..e926a18 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -205,6 +205,8 @@
 0x00802006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  assign_vector [ irq = %(1)d = 
vector 0x%(2)x, CPU mask: 0x%(3)08x ]
 0x00802007  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  bogus_vector [ 0x%(1)x ]
 0x00802008  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  do_irq [ irq = %(1)d, began = 
%(2)dus, ended = %(3)dus ]
+0x00804001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  pi_list_add [ domid = 
0x%(1)04x vcpu = 0x%(2)04x, pcpu = 0x%(3)04x, #entry = 0x%(4)04x ]
+0x00804002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  pi_list_del [ domid = 
0x%(1)04x vcpu = 0x%(2)04x ]
 
 0x00084001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  hpet create [ tn = %(1)d, irq 
= %(2)d, delta = 0x%(4)08x%(3)08x, period = 0x%(6)08x%(5)08x ]
 0x00084002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  pit create [ delta = 
0x%(1)016x, period = 0x%(2)016x ]
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 24cce2a..2276a23 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -159,6 +159,7 @@ struct {
 scatterplot_extint_cycles:1,
 scatterplot_rdtsc:1,
 scatterplot_irq:1,
+scatterplot_pi_list:1,
 histogram_interrupt_eip:1,
 interval_mode:1,
 dump_all:1,
@@ -233,6 +234,7 @@ struct {
 .scatterplot_extint_cycles=0,
 .scatterplot_rdtsc=0,
 .scatterplot_irq=0,
+.scatterplot_pi_list=0,
 .histogram_interrupt_eip=0,
 .dump_all = 0,
 .dump_raw_process = 0,
@@ -1391,6 +1393,9 @@ struct hvm_data {
 
 /* Historical info */
 tsc_t last_rdtsc;
+
+/* Destination pcpu of posted interrupt's wakeup interrupt */
+int pi_cpu;
 };
 
 enum {
@@ -1457,6 +1462,8 @@ void init_hvm_data(struct hvm_data *h, struct vcpu_data 
*v) {
 }
 for(i=0; isummary.guest_interrupt[i].count=0;
+
+h->pi_cpu = -1;
 }
 
 /* PV data */
@@ -1852,6 +1859,9 @@ struct pcpu_info {
 tsc_t tsc;
 struct cycle_summary idle, running, lost;
 } time;
+
+/* Posted Interrupt List Length */
+int pi_list_length;
 };
 
 void __fill_in_record_info(struct pcpu_info *p);
@@ -8581,8 +8591,97 @@ void irq_process(struct pcpu_info *p) {
 }
 }
 
+static void process_pi_list_add(struct record_info *ri)
+{
+struct {
+int did;
+int vid;
+int pcpu;
+int len;
+} *data = (typeof(data))ri->d;
+struct vcpu_data *v;
+
+v = vcpu_find(data->did, data->vid);
+if ( !v->hvm.init )
+init_hvm_data(>hvm, v);
+
+if ( opt.dump_all )
+printf("d%uv%u is added to pi blocking list of pcpu%u. "
+   "The list length is now %d\n",
+   data->did, data->vid, data->pcpu, data->len);
+
+v->hvm.pi_cpu = data->pcpu;
+/* Calibrate pi list length */
+P.pcpu[data->pcpu].pi_list_length = data->len;
+
+if ( opt.scatterplot_pi_list )
+{
+struct time_struct t;
+
+abs_cycles_to_time(ri->tsc, );
+printf("%d %u.%09u %d\n", data->pcpu, t.s, t.ns,
+   P.pcpu[data->pcpu].pi_list_length);
+}
+}
+
+static void process_pi_list_del(struct record_info *ri)
+{
+struct {
+int did;
+int vid;
+} *data = (typeof(data))ri->d;
+struct vcpu_data *v;
+
+v = vcpu_find(data->did, data->vid);
+if ( !v->hvm.init )
+init_hvm_data(>hvm, v);
+
+if ( opt.dump_all )
+{
+if ( v->hvm.pi_cpu != -1 )
+printf("d%uv%u is removed from pi blocking list of pcpu%u\n",
+   data->did, data->vid, v->hvm.pi_cpu);
+else
+printf("d%uv%u is removed from pi blocking list\n",
+   data->did, data->vid);
+}
+
+if ( (v->hvm.pi_cpu != -1) && (P.pcpu[v->hvm.pi_cpu].pi_list_length != -1) 
)
+{
+P.pcpu[v->hvm.pi_cpu].pi_list_length--;
+
+if ( opt.scatterplot_pi_list )
+{
+struct time_struct t;
+
+abs_cycles_to_time(ri->tsc, );
+printf("%d %u.%09u %d\n", v->hvm.pi_cpu, t.s, t.ns,
+   P.pcpu[v->hvm.pi_cpu].pi_list_length);
+}
+}
+v->hvm.pi_cpu = -1;
+}
+
+
+static void vtd_process(struct pcpu_info *p) {
+struct record_info *ri = >ri;
+
+

[Xen-devel] [PATCH v5 1/4] VT-d PI: track the number of vcpus on pi blocking list

This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track
how many entries are on the pi blocking list.

Signed-off-by: Chao Gao 
---
v5:
 - introduce two functions for adding or removing vcpus from pi blocking list.
 - check the sanity of vcpu count on pi blocking list
v4:
 - non-trace part of Patch 1 in v3

---
 xen/arch/x86/hvm/vmx/vmx.c | 42 --
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 67fc85b..bf17988 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -83,6 +83,7 @@ static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
 struct vmx_pi_blocking_vcpu {
 struct list_head list;
 spinlock_t   lock;
+unsigned int counter;
 };
 
 /*
@@ -100,6 +101,24 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
 spin_lock_init(_cpu(vmx_pi_blocking, cpu).lock);
 }
 
+static void vmx_pi_add_vcpu(struct pi_blocking_vcpu *pbv,
+struct vmx_pi_blocking_vcpu *vpbv)
+{
+ASSERT(spin_is_locked(>lock));
+add_sized(>counter, 1);
+ASSERT(read_atomic(>counter));
+list_add_tail(>list, >list);
+}
+
+static void vmx_pi_del_vcpu(struct pi_blocking_vcpu *pbv,
+struct vmx_pi_blocking_vcpu *vpbv)
+{
+ASSERT(spin_is_locked(>lock));
+ASSERT(read_atomic(>counter));
+list_del(>list);
+add_sized(>counter, -1);
+}
+
 static void vmx_vcpu_block(struct vcpu *v)
 {
 unsigned long flags;
@@ -120,8 +139,8 @@ static void vmx_vcpu_block(struct vcpu *v)
  */
 ASSERT(old_lock == NULL);
 
-list_add_tail(>arch.hvm_vmx.pi_blocking.list,
-  _cpu(vmx_pi_blocking, v->processor).list);
+vmx_pi_add_vcpu(>arch.hvm_vmx.pi_blocking,
+_cpu(vmx_pi_blocking, v->processor));
 spin_unlock_irqrestore(pi_blocking_list_lock, flags);
 
 ASSERT(!pi_test_sn(pi_desc));
@@ -186,7 +205,9 @@ static void vmx_pi_unblock_vcpu(struct vcpu *v)
 if ( v->arch.hvm_vmx.pi_blocking.lock != NULL )
 {
 ASSERT(v->arch.hvm_vmx.pi_blocking.lock == pi_blocking_list_lock);
-list_del(>arch.hvm_vmx.pi_blocking.list);
+vmx_pi_del_vcpu(>arch.hvm_vmx.pi_blocking,
+container_of(pi_blocking_list_lock,
+ struct vmx_pi_blocking_vcpu, lock));
 v->arch.hvm_vmx.pi_blocking.lock = NULL;
 }
 
@@ -234,7 +255,7 @@ void vmx_pi_desc_fixup(unsigned int cpu)
  */
 if ( pi_test_on(>pi_desc) )
 {
-list_del(>pi_blocking.list);
+vmx_pi_del_vcpu(>pi_blocking, _cpu(vmx_pi_blocking, cpu));
 vmx->pi_blocking.lock = NULL;
 vcpu_unblock(container_of(vmx, struct vcpu, arch.hvm_vmx));
 }
@@ -257,8 +278,9 @@ void vmx_pi_desc_fixup(unsigned int cpu)
 write_atomic(>pi_desc.ndst,
  x2apic_enabled ? dest : MASK_INSR(dest, 
PI_xAPIC_NDST_MASK));
 
-list_move(>pi_blocking.list,
-  _cpu(vmx_pi_blocking, new_cpu).list);
+vmx_pi_del_vcpu(>pi_blocking, _cpu(vmx_pi_blocking, cpu));
+vmx_pi_add_vcpu(>pi_blocking, _cpu(vmx_pi_blocking,
+new_cpu));
 vmx->pi_blocking.lock = new_lock;
 
 spin_unlock(new_lock);
@@ -2351,9 +2373,9 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
 {
 struct arch_vmx_struct *vmx, *tmp;
-spinlock_t *lock = _cpu(vmx_pi_blocking, smp_processor_id()).lock;
-struct list_head *blocked_vcpus =
-   _cpu(vmx_pi_blocking, smp_processor_id()).list;
+unsigned int cpu = smp_processor_id();
+spinlock_t *lock = _cpu(vmx_pi_blocking, cpu).lock;
+struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
 
 ack_APIC_irq();
 this_cpu(irq_count)++;
@@ -2369,7 +2391,7 @@ static void pi_wakeup_interrupt(struct cpu_user_regs 
*regs)
 {
 if ( pi_test_on(>pi_desc) )
 {
-list_del(>pi_blocking.list);
+vmx_pi_del_vcpu(>pi_blocking, _cpu(vmx_pi_blocking, cpu));
 ASSERT(vmx->pi_blocking.lock == lock);
 vmx->pi_blocking.lock = NULL;
 vcpu_unblock(container_of(vmx, struct vcpu, arch.hvm_vmx));
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 0/4] mitigate the per-pCPU blocking list may be too long

Changes in v5:
- In patch 1, add check the sanity of vcpus count on pi blocking list
and also drop George's Reviewed-by.
- In patch 3, introduce a new function to find proper pCPU to accept
the blocked vcpu.
- In patch 4, add support of tracking the operations on pi blocking list
and generating scatterplot of pi list length

VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU
on a given pCPU. Theoretically, there are 32K domain on single host,
128 vCPUs per domain. If all vCPUs are blocked on the same pCPU,
4M vCPUs are in the same list. Traversing this list consumes too
much time. More discussion can be found in [1,2,3].

To mitigate this issue, this series put vcpus to another pcpu's list
when the local pcpu's list length reachs an upper bound which is the
average vcpus per pcpu ratio plus a constant.

PATCH 1/4 adds a counter to track the per-pCPU blocking list's length.

PATCH 2/4 uses a global variable to track how many hvm vcpus on this
system. It is used to calculate the average vcpus per pcpu ratio.

patch 3/4 employs a policy to restrict the vcpu count on a given
pcpu's pi blocking list in case the list grows too long. In one work,
If list length is smaller than the upper bound, the vcpu is added to
the pi blocking list of the pcpu which it is running on. Otherwise,
another online pcpu is chosen to accept the vcpu.

patch 4/4 adds some relevant events to xentrace to aid analysis of
the list length. With this patch, some data can be acquired to
validate patch 3/4.

[1]
https://lists.gt.net/xen/devel/422661?search_string=VT-d%20posted-interrupt%20core%20logic%20handling;#422661
[2]
https://lists.gt.net/xen/devel/422567?search_string=%20The%20length%20of%20the%20list%20depends;#422567
[3]
https://lists.gt.net/xen/devel/472749?search_string=enable%20vt-d%20pi%20by%20default;#472749

Chao Gao (4):
VT-d PI: track the number of vcpus on pi blocking list
x86/vcpu: track hvm vcpu number on the system
VT-d PI: restrict the number of vcpus in a given pcpu's PI blocking
list
xentrace: add support for HVM's PI blocking list operation

--
1.8.3.1

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

[Xen-devel] [PATCH v5 2/4] x86/vcpu: track hvm vcpu number on the system

This number is used to calculate the average vcpus per pcpu ratio.

Signed-off-by: Chao Gao 
Acked-by: Jan Beulich 
---
v4:
 - move the place we increase/decrease the hvm vcpu number to
 hvm_vcpu_{initialise, destory}

---
 xen/arch/x86/hvm/hvm.c| 6 ++
 xen/include/asm-x86/hvm/hvm.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 555133f..37afdb4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -109,6 +109,9 @@ static const char __initconst warning_hvm_fep[] =
 static bool_t __initdata opt_altp2m_enabled = 0;
 boolean_param("altp2m", opt_altp2m_enabled);
 
+/* Total number of HVM vCPUs on this system */
+atomic_t num_hvm_vcpus;
+
 static int cpu_callback(
 struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -1511,6 +1514,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
 
 hvm_update_guest_vendor(v);
 
+atomic_inc(_hvm_vcpus);
 return 0;
 
  fail6:
@@ -1529,6 +1533,8 @@ int hvm_vcpu_initialise(struct vcpu *v)
 
 void hvm_vcpu_destroy(struct vcpu *v)
 {
+atomic_dec(_hvm_vcpus);
+
 viridian_vcpu_deinit(v);
 
 hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index b687e03..c51bd9f 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_HVM_FEP
@@ -233,6 +234,8 @@ extern bool_t hvm_enabled;
 extern bool_t cpu_has_lmsl;
 extern s8 hvm_port80_allowed;
 
+extern atomic_t num_hvm_vcpus;
+
 extern const struct hvm_function_table *start_svm(void);
 extern const struct hvm_function_table *start_vmx(void);
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 3/4] VT-d PI: restrict the number of vcpus in a given pcpu's PI blocking list

Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
too many vCPUs are blocked on a given pCPU, it will incur that the list
grows too long. After a simple analysis, there are 32k domains and
128 vcpu per domain, thus about 4M vCPUs may be blocked in one pCPU's
PI blocking list. When a wakeup interrupt arrives, the list is
traversed to wake up vCPUs which have events pending. This traversal in
that case would consume much time.

To mitigate this issue, this patch limits the number of vCPUs tracked by a
given pCPU's blocking list, taking factors such as perfomance of common case,
current hvm vCPU count and current pCPU count into consideration. With this
method, for the common case, it works fast and for some extreme cases, the
list length is under control.

With this patch, when a vcpu is to be blocked, we check whether the pi
blocking list's length of the pcpu where the vcpu is running exceeds
the limit which is the average vcpus per pcpu ratio plus a constant.
If no, the vcpu is added to this pcpu's pi blocking list. Otherwise,
another online pcpu is chosen to accept the vcpu.

Signed-off-by: Chao Gao 
---
v5:
 - Introduce a function to choose the suitable pcpu to accept the blocked
 vcpu.
v4:
 - use a new lock to avoid adding a blocked vcpu to a offline pcpu's blocking
 list.

---
 xen/arch/x86/hvm/vmx/vmx.c | 109 -
 1 file changed, 97 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bf17988..646f409 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -119,16 +119,85 @@ static void vmx_pi_del_vcpu(struct pi_blocking_vcpu *pbv,
 add_sized(>counter, -1);
 }
 
+/*
+ * By default, the local pcpu (namely, the one the vcpu is currently running 
on)
+ * is chosen as the destination of wakeup interrupt. But if the number of vcpus
+ * in the default pcpu's PI blocking list exceeds a limit, another suitable
+ * pcpu is chosen as the destination by iterating through all online pcpus.
+ *
+ * Currently, choose (v_tot/p_tot) + K as the limit of vcpus, where
+ * v_tot is the total number of hvm vcpus on the system, p_tot is the total
+ * number of pcpus in the system, and K is a fixed number. An experiment on a
+ * skylake server which has 112 cpus and 64G memory shows the maximum time of
+ * waking up a vcpu from a 128-entry blocking list is about 22us, which is
+ * tolerable. So choose 128 as the fixed number K.
+ *
+ * This policy makes sure:
+ * 1) for common cases, the limit won't be reached and the local pcpu is used
+ * which is beneficial to performance (at least, avoid an IPI when unblocking
+ * vcpu).
+ * 2) for the worst case, the blocking list length scales with the vcpu count
+ * divided by the pcpu count.
+ */
+#define PI_LIST_FIXED_LIMIT 128
+
+static inline bool pi_over_limit(unsigned int cpu)
+{
+/* Compare w/ constant first to save a division and an add */
+if ( likely(read_atomic(_cpu(vmx_pi_blocking, cpu).counter) <=
+PI_LIST_FIXED_LIMIT) )
+return 0;
+else
+return read_atomic(_cpu(vmx_pi_blocking, cpu).counter) >=
+   (atomic_read(_hvm_vcpus) / num_online_cpus()) +
+   PI_LIST_FIXED_LIMIT;
+}
+
+/*
+ * Start from @cpu and iterate cpu_online_map to look for one cpu whose
+ * blocking list length is under limit. Return with holding a lock to avoid
+ * others adding entries to the chosen cpu.
+ * There must be at least one suitable cpu for the limit is greater than the
+ * average number of all cpus' blocking list length.
+ */
+static unsigned int pi_get_blocking_cpu(unsigned int cpu, unsigned long *flags)
+{
+spinlock_t *pi_blocking_list_lock;
+
+for ( ; ; )
+{
+while ( unlikely(pi_over_limit(cpu)) )
+cpu = cpumask_cycle(cpu, _online_map);
+
+pi_blocking_list_lock = _cpu(vmx_pi_blocking, cpu).lock;
+if ( flags )
+spin_lock_irqsave(pi_blocking_list_lock, *flags);
+else
+spin_lock(pi_blocking_list_lock);
+/*
+ * check again in case the list length exceeds the limit during taking
+ * the lock
+ */
+if ( !pi_over_limit(cpu) )
+break;
+else if ( flags )
+spin_unlock_irqrestore(pi_blocking_list_lock, *flags);
+else
+spin_unlock(pi_blocking_list_lock);
+}
+
+return cpu;
+}
+
 static void vmx_vcpu_block(struct vcpu *v)
 {
 unsigned long flags;
-unsigned int dest;
-spinlock_t *old_lock;
-spinlock_t *pi_blocking_list_lock =
-   _cpu(vmx_pi_blocking, v->processor).lock;
+unsigned int dest, pi_cpu;
+spinlock_t *old_lock, *pi_blocking_list_lock;
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
 
-spin_lock_irqsave(pi_blocking_list_lock, flags);
+pi_cpu = pi_get_blocking_cpu(v->processor, );
+pi_blocking_list_lock =

[Xen-devel] [PATCH v6] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

The problem is for a VF of RC integrated PF (e.g. PF's BDF is
00:02.0), we would wrongly use 00:00.0 to search VT-d unit.

If a PF is an extended function, the BDF of a traditional function
within the same device should be used to search VT-d unit. Otherwise,
the real BDF of PF should be used. According PCI-e spec, an extended
function is a function within an ARI device and Function Number is
greater than 7. The original code tried to tell apart Extended
Function and non-Extended Function through checking PCI_SLOT(),
missing counterpart of pci_ari_enabled() (this function exists in
linux kernel) compared to linux kernel. Without checking whether ARI
is enabled, it incurs a RC integrated PF with PCI_SLOT() >0 is wrongly
classified to an extended function. Note that a RC integrated function
isn't within an ARI device and thus cannot be extended function and in
this case the real BDF should be used.

This patch introduces a new field, pf_is_extfn, in struct
pci_dev_info, to indicate whether the physical function is an extended
function. The new field helps to generate correct BDF to search VT-d
unit.

Reported-by: Crawford, Eric R 
Tested-by: Crawford, Eric R 
Signed-off-by: Chao Gao 
---
 xen/drivers/passthrough/pci.c  | 6 +-
 xen/drivers/passthrough/vtd/dmar.c | 2 +-
 xen/include/xen/pci.h  | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27bdb71..8c2ba33 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -599,6 +599,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
 const char *pdev_type;
 int ret;
+bool pf_is_extfn = false;
 
 if (!info)
 pdev_type = "device";
@@ -609,7 +610,9 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 pcidevs_lock();
 pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
 pcidevs_unlock();
-if ( !pdev )
+if ( pdev )
+pf_is_extfn = pdev->info.is_extfn;
+else
 pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
NULL, node);
 pdev_type = "virtual function";
@@ -707,6 +710,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
seg, bus, slot, func, ctrl);
 }
 
+pdev->info.pf_is_extfn = pf_is_extfn;
 check_pdev(pdev);
 
 ret = 0;
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..a96558f 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -219,7 +219,7 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const 
struct pci_dev *pdev)
 else if ( pdev->info.is_virtfn )
 {
 bus = pdev->info.physfn.bus;
-devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
pdev->info.physfn.devfn;
+devfn = pdev->info.pf_is_extfn ? 0 : pdev->info.physfn.devfn;
 }
 else
 {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a..9e76aa0 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -40,6 +40,7 @@
 
 struct pci_dev_info {
 bool_t is_extfn;
+bool_t pf_is_extfn; /* Only valid for virtual function */
 bool_t is_virtfn;
 struct {
 u8 bus;
-- 
1.8.3.1


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

[Xen-devel] [xen-4.9-testing test] 112647: tolerable trouble: blocked/broken/fail/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112461
 build-arm64-pvops 2 hosts-allocate  broken like 112461
 build-arm64-xsm   2 hosts-allocate  broken like 112461
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 112449
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112449
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112461
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112461
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112461
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0e186e33c0487a81c48dccdede206e63db22dd7d
baseline version:
 xen  f4f02f121f271ee0722723e393226687b42e29a1

Last test of basis   112461  2017-08-05 05:23:33 Z   10 days
Testing same since   112647  2017-08-15 13:42:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson

Re: [Xen-devel] [PATCH v1 05/13] x86: implement get hw info flow for MBA

2017-08-15 Thread Chao Peng

On Wed, 2017-08-09 at 15:41 +0800, Yi Sun wrote:
> This patch implements get HW info flow for MBA including its callback
> function and sysctl interface.
> 
> Signed-off-by: Yi Sun 
> ---
> v1:
> - sort 'PSR_INFO_IDX_' macros as feature.
>   (suggested by Chao Peng)
> - rename 'PSR_INFO_IDX_MBA_LINEAR' to 'PSR_INFO_IDX_MBA_FLAG'.
> - rename 'linear' in 'struct mba_info' to 'flags' for future
> extension.
>   (suggested by Chao Peng)
> ---
>  xen/arch/x86/psr.c  | 13 -
>  xen/arch/x86/sysctl.c   | 19 +++
>  xen/include/asm-x86/psr.h   |  2 ++
>  xen/include/public/sysctl.h |  8 
>  4 files changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index d94a5b1..9455e67 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -264,6 +264,10 @@ static enum psr_feat_type
> psr_val_type_to_feat_type(enum psr_val_type type)
>  feat_type = FEAT_TYPE_L2_CAT;
>  break;
>  
> +case PSR_VAL_TYPE_MBA:
> +feat_type = FEAT_TYPE_MBA;
> +break;
> +
>  default:
>  ASSERT_UNREACHABLE();
>  }
> @@ -490,7 +494,14 @@ static const struct feat_props l2_cat_props = {
>  static bool mba_get_feat_info(const struct feat_node *feat,
>    uint32_t data[], unsigned int
> array_len)
>  {
> -return false;
> +if ( array_len != PSR_INFO_ARRAY_SIZE )
> +return false;
> +
> +data[PSR_INFO_IDX_COS_MAX] = feat->cos_max;
> +data[PSR_INFO_IDX_MBA_THRTL_MAX] = feat->mba_info.thrtl_max;
> +data[PSR_INFO_IDX_MBA_FLAG] = feat->mba_info.linear;

Once it becomes a flag, then good practice would be operating it as a
flag. E.g. here assigning a bool value to a flag bit is error-prone once
more bits get used. Like XEN_SYSCTL_PSR_CAT_L3_CDP, you can set/clear
XEN_SYSCTL_PSR_MBA_LINEAR bit respectively.

Chao

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

[Xen-devel] [GIT PULL] (xen) stable/for-jens-4.13 for rc5

2017-08-15 Thread Konrad Rzeszutek Wilk

Hey Jens,

Please git pull the following branch:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.13

which has two fixes, both of them spotted by Amazon.

 1) Fix in Xen-blkfront caused by the re-write in 4.8 time-frame.
 2) Fix in the xen_biovec_phys_mergeable which allowed guest
requests when using NVMe - to slurp up more data than allowed
leading to an XSA (which has been made public today).

Thanks!

 drivers/block/xen-blkfront.c | 6 +++---
 drivers/xen/biomerge.c   | 3 +--
 2 files changed, 4 insertions(+), 5 deletions(-)

Munehisa Kamata (1):
  xen-blkfront: use a right index when checking requests

Roger Pau Monne (1):
  xen: fix bio vec merging


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

Re: [Xen-devel] [PATCH v1 04/13] x86: implement data structure and CPU init flow for MBA

2017-08-15 Thread Chao Peng

On Wed, 2017-08-09 at 15:41 +0800, Yi Sun wrote:
> This patch implements main data structures of MBA.
> 
> Like CAT features, MBA HW info has cos_max which means the max cos
> registers number, and thrtl_max which means the max throttle value

Similarly, there is no existence of 'cos register', 'cos number' is even
better or anything else.

> (delay value). It also has a flag to represent if the throttle
> value is linear or not.
> 
> One COS register of MBA stores a throttle value for one or more

Ditto.
                                                         ^s
...

> -/* CAT common functions implementation. */
> +/* Implementation of allocation features' functions. */
>  static int cat_init_feature(const struct cpuid_leaf *regs,
>  struct feat_node *feat,
>  struct psr_socket_info *info,
> @@ -289,7 +310,6 @@ static int cat_init_feature(const struct
> cpuid_leaf *regs,
>  if ( !regs->a || !regs->d )
>  return -ENOENT;
>  
> -feat->cbm_len = (regs->a & CAT_CBM_LEN_MASK) + 1;

Does this have to be moved?

...

> +
> +feat->cos_reg_val[0] = 0;
> +wrmsrl(MSR_IA32_PSR_MBA_MASK(0), 0);

It's better to have a comment here to explain what the defaul value '0'
stands for in both linear mode and non-linear mode.

Chao

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

Re: [Xen-devel] [PATCH v1 01/13] docs: create Memory Bandwidth Allocation (MBA) feature document

2017-08-15 Thread Yi Sun

On 17-08-15 11:08:32, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 03:41:40PM +0800, Yi Sun wrote:
> > +# Overview
> > +
> > +The Memory Bandwidth Allocation (MBA) feature provides indirect and 
> > approximate
> > +control over memory bandwidth available per-core. This feature provides OS/
> > +hypervisor the ability to slow misbehaving apps/domains or create advanced
> > +closed-loop control system via exposing control over a credit-based 
> > throttling
> > +mechanism.
> > +
> > +# User details
> > +
> > +* Feature Enabling:
> > +
> > +  Add "psr=mba" to boot line parameter to enable MBA feature.
> > +
> > +* xl interfaces:
> > +
> > +  1. `psr-mba-show [domain-id]`:
> > +
> > + Show memory bandwidth throttling for domain.
> > +
> > +  2. `psr-mba-set [OPTIONS] domain-id throttling`:
> > +
> 
> When specifying arguments to a command, we normally use the form
>  and [optional_argument].

Got it, thanks! Will change these.

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

Re: [Xen-devel] [PATCH v1 02/13] Rename PSR sysctl/domctl interfaces and xsm policy to make them be general

2017-08-15 Thread Yi Sun

On 17-08-15 11:12:36, Wei Liu wrote:
> You forgot to CC XSM maintainer. I have done that for you.
> 
Thank you!

> On Wed, Aug 09, 2017 at 03:41:41PM +0800, Yi Sun wrote:
> > This patch renames PSR sysctl/domctl interfaces and related xsm policy to
> > make them be general for all resource allocation features but not only
> > for CAT. Then, we can resuse the interfaces for all allocation features.
> > 
> > Basically, it changes 'cat' to 'alloc'. E.g.:
> > 1. psr_cat_op -> psr_alloc_op
> > 2. XEN_DOMCTL_psr_cat_op -> XEN_DOMCTL_psr_alloc_op
> > 3. XEN_SYSCTL_psr_cat_op -> XEN_SYSCTL_psr_alloc_op
> > 
> > The sysctl/domctl version numbers are bumped.
> > 
> > Signed-off-by: Yi Sun 
> 
> Subject to an ack / review from relevant maintainers:
> 
> Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1 03/13] x86: rename 'cbm_type' to 'psr_val_type' to make it general

2017-08-15 Thread Chao Peng

> -enum cbm_type {
> -PSR_CBM_TYPE_L3,
> -PSR_CBM_TYPE_L3_CODE,
> -PSR_CBM_TYPE_L3_DATA,
> -PSR_CBM_TYPE_L2,
> -PSR_CBM_TYPE_UNKNOWN,
> +enum psr_val_type {
> +PSR_VAL_TYPE_L3,
> +PSR_VAL_TYPE_L3_CODE,
> +PSR_VAL_TYPE_L3_DATA,
> +PSR_VAL_TYPE_L2,
> +PSR_VAL_TYPE_UNKNOWN,

I'd like to change PSR_CBM_TYPE_* to PSR_VAL_TYPE_*_CBM to be more
specific, E.g. PSR_CBM_TYPE_L3 => PSR_VAL_TYPE_L3_CBM.

Chao


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

[Xen-devel] [qemu-mainline test] 112646: tolerable trouble: blocked/broken/fail/pass - PUSHED

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112610

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112610
 build-arm64   2 hosts-allocate  broken like 112610
 build-arm64-xsm   3 capture-logsbroken like 112610
 build-arm64   3 capture-logsbroken like 112610
 build-arm64-pvops 2 hosts-allocate  broken like 112610
 build-arm64-pvops 3 capture-logsbroken like 112610
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
112610
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112610
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112610
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112610
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112610
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112610
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuuc4a6a8887c1b2a669e35ff9da9530824300bdce4
baseline version:
 qemuu9db6ffc76676731a25a5538ab71e8ca6ac234f80

Last test of basis   112610  2017-08-12 15:47:13 Z3 days
Failing since112631  2017-08-14 11:20:02 Z1 days3 attempts
Testing same since   112646  2017-08-15 13:30:37 Z0 days1 attempts


People who touched revisions under test:
  Cleber Rosa 
  Cornelia Huck 
  Eduardo Otubo 
  Eric Blake 
  Eric Farman 
  Fam Zheng 
  Jason Wang 
  KONRAD Frederic 
  Michael Tokarev

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

2017-08-15 Thread Steven Rostedt

On Fri, 11 Aug 2017 14:07:14 +0200
Peter Zijlstra  wrote:

> It goes like:
> 
>   CPU0CPU1
> 
>   unhook page
>   cli
>   traverse page tables
>   TLB invalidate ---> 
>   sti
>   
>TLB invalidate
>   <--  complete

I guess the important part here is the above "complete". CPU0 doesn't
proceed until its receives it. Thus it does act like
cli~rcu_read_lock(), sti~rcu_read_unlock(), and "TLB invalidate" is
equivalent to synchronize_rcu().

[ this response is for clarification for the casual observer of this
  thread ;-) ]

-- Steve

>   
>   free page
> 
> So the CPU1 page-table walker gets an existence guarantee of the
> page-tables by clearing IF.

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

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

2017-08-15 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a6b3d753f98118ee547ae935b347f4f00fa67e7c
baseline version:
 ovmf 4ad5f597153c7cb20a968236c2c7d6ff01994350

Last test of basis71975  2017-08-15 03:47:26 Z0 days
Testing same since71977  2017-08-15 20:47:23 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



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

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

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


Push not applicable.


commit a6b3d753f98118ee547ae935b347f4f00fa67e7c
Author: Star Zeng 
Date:   Fri Aug 4 10:05:20 2017 +0800

UefiCpuPkg MpInitLib: Save/restore original WakeupBuffer for DxeMpLib

Current code always allocates/frees < 1MB WakeupBuffer for DxeMpLib
until ExitBootService, but the allocation may be failed at late
phase of the boot.

This patch is to always save/restore original WakeupBuffer for
DxeMpLib, it is aligned with the solution for PeiMpLib at
9293d6e42e677e4a38e055258c0993ad8a9df14e, then AllocateResetVector()
and FreeResetVector() will be common and moved to MpLib.c.
Only difference is GetWakeupBuffer() that will be in PeiMpLib or
DxeMpLib respectively.

Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Eric Dong 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Liming Gao 

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

Re: [Xen-devel] [PATCH v5] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-15 Thread Tamas K Lengyel

On Tue, Aug 15, 2017 at 2:06 AM, Jan Beulich  wrote:
 On 14.08.17 at 17:53,  wrote:
>> On Tue, Aug 8, 2017 at 2:27 AM, Alexandru Isaila  
>> wrote:
>>> --- a/xen/arch/x86/hvm/hypercall.c
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
>>>  /* Fallthrough to permission check. */
>>>  case 4:
>>>  case 2:
>>> +if ( currd->arch.monitor.guest_request_userspace_enabled &&
>>> +eax == __HYPERVISOR_hvm_op &&
>>> +(mode == 8 ? regs->rdi : regs->ebx) == 
>>> HVMOP_guest_request_vm_event )
>>> +break;
>>> +
>>
>> So the CPL check happens after the monitor check, which means this
>> will trigger regardless if the hypercall is coming from userspace or
>> kernelspace. Since the monitor option specifically says userspace,
>> this should probably get moved into the block where CPL was checked.
>
> What difference would this make? For CPL0 the hypercall is
> permitted anyway, and for CPL > 0 we specifically want to bypass
> the CPL check. Or are you saying you want to restrict the new
> check to just CPL3?
>

Yes, according to the name of this monitor option this should only
trigger a vm_event when the hypercall is coming from CPL3. However,
the way it is implemented right now I see that this monitor option
actually requires the other one to be enabled too. By itself this
monitor option will not work. So I would also like to ask that the
check in xen/common/monitor.c, if ( d->monitor.guest_request_enabled
), to be extended to be: if ( d->monitor.guest_request_enabled ||
d->monitor.guest_request_userspace_enabled )

Tamas

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

Re: [Xen-devel] [PATCH v06 26/36] uapi xen/privcmd.h: fix compilation in userspace

On Sun, 6 Aug 2017, Mikko Rapeli wrote:
> xen/interface/xen.h is not exported from kernel headers so remove the
> dependency and provide needed defines for domid_t and xen_pfn_t if they
> are not already defined by some other e.g. Xen specific headers.
> 
> Suggested by Andrew Cooper  on lkml message
> <5569f9c9.8000...@citrix.com>.
> 
> The ifdef for ARM is ugly but did not find better solutions for it.
> 
> Then use __kernel_size_t instead of size_t since that is available in
> uapi headers in user space.
> 
> Fixes userspace compilation errors:
> 
> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or 
> directory
> xen/privcmd.h:92:2: error: unknown type name ‘size_t’
> 
> Signed-off-by: Mikko Rapeli 
> Cc: Paul Durrant 
> Cc: David Vrabel 
> Cc: Stefano Stabellini 
> Cc: Russell King 

Reviewed-by: Stefano Stabellini 

> ---
>  include/uapi/xen/privcmd.h | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
> index 63ee95c9dabb..565f3003741d 100644
> --- a/include/uapi/xen/privcmd.h
> +++ b/include/uapi/xen/privcmd.h
> @@ -35,7 +35,17 @@
>  
>  #include 
>  #include 
> -#include 
> +
> +/* Defined by include/xen/interface/xen.h, but it is not part of Linux uapi 
> */
> +#ifndef __XEN_PUBLIC_XEN_H__
> +typedef __u16 domid_t;
> +
> +#if (defined __ARMEL__ || defined __ARMEB__)
> +typedef __u64 xen_pfn_t;
> +#else
> +typedef unsigned long xen_pfn_t;
> +#endif /* (defined __ARMEL__ || defined __ARMEB__) */
> +#endif /* __XEN_PUBLIC_XEN_H__ */
>  
>  struct privcmd_hypercall {
>   __u64 op;
> @@ -79,7 +89,7 @@ struct privcmd_mmapbatch_v2 {
>  
>  struct privcmd_dm_op_buf {
>   void __user *uptr;
> - size_t size;
> + __kernel_size_t size;
>  };
>  
>  struct privcmd_dm_op {
> -- 
> 2.13.3
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.9 test] 112643: tolerable trouble: blocked/broken/fail/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112637 
pass in 112643
 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 112637

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112513
 build-arm64-pvops 3 capture-logsbroken like 112513
 build-arm64   2 hosts-allocate  broken like 112513
 build-arm64   3 capture-logsbroken like 112513
 build-arm64-xsm   2 hosts-allocate  broken like 112513
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112637 
blocked in 112513
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112637 
like 112513
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 112637 like 
112513
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 112637 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 112637 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 112497
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112513
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112513
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112513
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112513
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never

Re: [Xen-devel] [PATCH v8 11/13] arm/mem_access: Add long-descriptor based gpt

On 15/08/2017 23:25, Stefano Stabellini wrote:
> On Tue, 15 Aug 2017, Julien Grall wrote:
>> On 14/08/17 22:03, Sergej Proskurin wrote:
>>> Hi Julien,
>>>
>>> On 08/14/2017 07:37 PM, Julien Grall wrote:
 Hi Sergej,

 On 09/08/17 09:20, Sergej Proskurin wrote:
> +/*
> + * According to to ARM DDI 0487B.a J1-5927, we return an error if
> the found
 Please drop one of the 'to'. The rest looks good to me.

>>> Great, thanks. I will remove the second "to" in v9. Would that be an
>>> Acked-by or shall I tag this patch with a Reviewed-by you?
>> Acked-by. FIY, you still missing an acked from "The REST" for patch #7, the
>> rest looks fully acked.
> I acked patch #7, but patch #8 breaks the build on ARM:
>
>
> In file included from 
> /local/repos/xen-upstream/xen/include/xen/guest_access.h:10:0,
>  from device_tree.c:15:
> /local/repos/xen-upstream/xen/include/asm/guest_access.h:14:32: error: 
> 'struct domain' declared inside parameter list [-Werror]
> uint32_t size, bool_t is_write);
> ^
> /local/repos/xen-upstream/xen/include/asm/guest_access.h:14:32: error: its 
> scope is only this definition or declaration, which is probably not what you 
> want [-Werror]
> cc1: all warnings being treated as errors
> make[4]: *** [device_tree.o] Error 1
>
>
> Am I missing anything?

Possibly a result of Wei's recent patch
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=de62402a9c2e403b049aa238b4fa4e2d618e8870
which is newer than the posting of this series.

~Andrew

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

Re: [Xen-devel] [PATCH v8 11/13] arm/mem_access: Add long-descriptor based gpt

On Tue, 15 Aug 2017, Julien Grall wrote:
> On 14/08/17 22:03, Sergej Proskurin wrote:
> > Hi Julien,
> > 
> > On 08/14/2017 07:37 PM, Julien Grall wrote:
> > > Hi Sergej,
> > > 
> > > On 09/08/17 09:20, Sergej Proskurin wrote:
> > > > +/*
> > > > + * According to to ARM DDI 0487B.a J1-5927, we return an error if
> > > > the found
> > > 
> > > Please drop one of the 'to'. The rest looks good to me.
> > > 
> > 
> > Great, thanks. I will remove the second "to" in v9. Would that be an
> > Acked-by or shall I tag this patch with a Reviewed-by you?
> 
> Acked-by. FIY, you still missing an acked from "The REST" for patch #7, the
> rest looks fully acked.

I acked patch #7, but patch #8 breaks the build on ARM:


In file included from 
/local/repos/xen-upstream/xen/include/xen/guest_access.h:10:0,
 from device_tree.c:15:
/local/repos/xen-upstream/xen/include/asm/guest_access.h:14:32: error: 'struct 
domain' declared inside parameter list [-Werror]
uint32_t size, bool_t is_write);
^
/local/repos/xen-upstream/xen/include/asm/guest_access.h:14:32: error: its 
scope is only this definition or declaration, which is probably not what you 
want [-Werror]
cc1: all warnings being treated as errors
make[4]: *** [device_tree.o] Error 1


Am I missing anything?

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

Re: [Xen-devel] [PATCH v8 07/13] arm/mem_access: Introduce GENMASK_ULL bit operation

On Wed, 9 Aug 2017, Sergej Proskurin wrote:
> The current implementation of GENMASK is capable of creating bitmasks of
> 32-bit values on AArch32 and 64-bit values on AArch64. As we need to
> create masks for 64-bit values on AArch32 as well, in this commit we
> introduce the GENMASK_ULL bit operation. Please note that the
> GENMASK_ULL implementation has been lifted from the linux kernel source
> code.
> 
> Signed-off-by: Sergej Proskurin 

Reviewed-by: Stefano Stabellini 


> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
> v6: As similar patches have been already submitted and NACKED in the
> past, we resubmit this patch with 'THE REST' maintainers in Cc to
> discuss whether this patch shall be applied into common or put into
> ARM related code.
> 
> v7: Change the introduced macro BITS_PER_LONG_LONG to BITS_PER_LLONG.
> 
> Define BITS_PER_LLONG also in asm-x86/config.h in order to allow
> global usage of the introduced macro GENMASK_ULL.
> 
> Remove previously unintended whitespace elimination in the function
> get_bitmask_order as it is not the right patch to address cleanup.
> ---
>  xen/include/asm-arm/config.h | 2 ++
>  xen/include/asm-x86/config.h | 2 ++
>  xen/include/xen/bitops.h | 3 +++
>  3 files changed, 7 insertions(+)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 5b6f3c985d..7da94698e1 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -19,6 +19,8 @@
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  #define POINTER_ALIGN BYTES_PER_LONG
>  
> +#define BITS_PER_LLONG 64
> +
>  /* xen_ulong_t is always 64 bits */
>  #define BITS_PER_XEN_ULONG 64
>  
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index bc0730fd9d..8b1de07dbc 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -15,6 +15,8 @@
>  #define BITS_PER_BYTE 8
>  #define POINTER_ALIGN BYTES_PER_LONG
>  
> +#define BITS_PER_LLONG 64
> +
>  #define BITS_PER_XEN_ULONG BITS_PER_LONG
>  
>  #define CONFIG_PAGING_ASSISTANCE 1
> diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> index bd0883ab22..e2019b02a3 100644
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -10,6 +10,9 @@
>  #define GENMASK(h, l) \
>  (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
>  
> +#define GENMASK_ULL(h, l) \
> +(((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LLONG - 1 - (h
> +
>  /*
>   * ffs: find first bit set. This is defined the same way as
>   * the libc and compiler builtin ffs routines, therefore
> -- 
> 2.13.3
> 

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

Re: [Xen-devel] [stage1-xen PATCH v1] init: Add `glide.lock`

On Tue, 15 Aug 2017, Rajiv Ranganath wrote:
> On Tue, Aug 15 2017 at 06:23:07 AM, Stefano Stabellini 
>  wrote:
> > Thank you for the patch. Usually the description that you sent in the
> > previous email is written here.
> >
> > I like the build.sh changes and I think introducing init/glide.yaml is a
> > great idea. But I don't think that introducing init/glide.lock is
> > necessary, is it? We could let glide generate it on the fly based on the
> > key versioning info already specified in glide.yaml.
> >
> > For example, this patch already introduces:
> >
> >   - package: github.com/containernetworking/cni
> > version: 0.3.0
> >
> > to glide.yaml. Are there any other reasons for committing glide.lock to
> > the repository instead of generating it?
> 
> I think the pattern of using `.lock` files to manage nested library
> dependencies and semantic versioning for library APIs was initially
> championed in the Ruby on Rails community. The idea has since been
> adopted by Go community in Glide, Rust community in Cargo and JavaScript
> community in Yarn.
> 
> Here is the link to the original discussion on whether `Gemfile.lock`
> should be checked into the source tree or not. [1]
> 
> If we go by author's line of reasoning, then answer would depend on if
> we consider init to be an app or a library.
> 
> Personally, I feel `init.go` is an app and it would make sense to check
> in `glide.lock`.
> 
> If for some reason, in future there is a build failure due to a nested
> dependency issue with dependent go libraries, then having a working
> `.lock` in the git is always useful.
> 
> In anycase after sending `BUILDING.md` Fedora patches, I am also
> planning on sending patches to do continuous build of `stage1-xen` in a
> Fedora based docker container. That should also catch build failures
> early.
> 
> Please let me know what you prefer. I can send a v2 of the patch with
> just `glide.yaml`

I read the explanation and I find it convincing. init.go is definitely
an app. I'll check in the patch as is.


> Best,
> Rajiv
> 
> [1] 
> http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/


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

[Xen-devel] [linux-3.18 test] 112642: trouble: blocked/broken/fail/pass

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 112634

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112634 
blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112634 
like 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112634 
like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112634 
like 112102
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass

Re: [Xen-devel] [PATCH v3 12/13] xen/pvcalls: implement release command

2017-08-15 Thread Boris Ostrovsky

On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> socket.
>
> For passive sockets, check whether we have already pre-allocated an
> active socket for the purpose of being accepted. If so, free that as
> well.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 88 
> +
>  drivers/xen/pvcalls-front.h |  1 +
>  2 files changed, 89 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 1c975d6..775a6d2 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -192,6 +192,23 @@ static irqreturn_t pvcalls_front_conn_handler(int irq, 
> void *sock_map)
>   return IRQ_HANDLED;
>  }
>  
> +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> +struct sock_mapping *map)
> +{
> + int i;
> +
> + spin_lock(>pvcallss_lock);
> + if (!list_empty(>list))
> + list_del_init(>list);
> + spin_unlock(>pvcallss_lock);
> +
> + for (i = 0; i < (1 << map->active.ring->ring_order); i++)
> + gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
> + gnttab_end_foreign_access(map->active.ref, 0, 0);
> + free_page((unsigned long)map->active.ring);
> + unbind_from_irqhandler(map->active.irq, map);

Would it better to first unbind the handler? Any chance an interrupt
might come in?

> +}
> +
>  int pvcalls_front_socket(struct socket *sock)
>  {
>   struct pvcalls_bedata *bedata;
> @@ -853,6 +870,77 @@ unsigned int pvcalls_front_poll(struct file *file, 
> struct socket *sock,
>   return pvcalls_front_poll_passive(file, bedata, map, wait);
>  }
>  
> +int pvcalls_front_release(struct socket *sock)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> + int req_id, notify, ret;
> + struct xen_pvcalls_request *req;
> +
> + if (!pvcalls_front_dev)
> + return -EIO;
> + bedata = dev_get_drvdata(_front_dev->dev);
> +
> + if (sock->sk == NULL)
> + return 0;

This can go above bedata access.

(You are going to address locking here so I won't review the rest)

-boris

> +
> + map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
> + if (map == NULL)
> + return 0;
> +
> + spin_lock(>pvcallss_lock);
> + ret = get_request(bedata, _id);
> + if (ret < 0) {
> + spin_unlock(>pvcallss_lock);
> + return ret;
> + }
> + WRITE_ONCE(sock->sk->sk_send_head, NULL);
> +
> + req = RING_GET_REQUEST(>ring, req_id);
> + req->req_id = req_id;
> + req->cmd = PVCALLS_RELEASE;
> + req->u.release.id = (uint64_t)map;
> +
> + bedata->ring.req_prod_pvt++;
> + RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
> + spin_unlock(>pvcallss_lock);
> + if (notify)
> + notify_remote_via_irq(bedata->irq);
> +
> + wait_event(bedata->inflight_req,
> +READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
> +
> + if (map->active_socket) {
> + /* 
> +  * Set in_error and wake up inflight_conn_req to force
> +  * recvmsg waiters to exit.
> +  */
> + map->active.ring->in_error = -EBADF;
> + wake_up_interruptible(>active.inflight_conn_req);
> +
> + mutex_lock(>active.in_mutex);
> + mutex_lock(>active.out_mutex);
> + pvcalls_front_free_map(bedata, map);
> + mutex_unlock(>active.out_mutex);
> + mutex_unlock(>active.in_mutex);
> + kfree(map);
> + } else {
> + spin_lock(>pvcallss_lock);
> + if (READ_ONCE(map->passive.inflight_req_id) !=
> + PVCALLS_INVALID_ID) {
> + pvcalls_front_free_map(bedata,
> +map->passive.accept_map);
> + kfree(map->passive.accept_map);
> + }
> + list_del_init(>list);
> + kfree(map);
> + spin_unlock(>pvcallss_lock);
> + }
> + WRITE_ONCE(bedata->rsp[req_id].req_id, PVCALLS_INVALID_ID);
> +
> + return 0;
> +}
> +
>  static const struct xenbus_device_id pvcalls_front_ids[] = {
>   { "pvcalls" },
>   { "" }
> diff --git a/drivers/xen/pvcalls-front.h b/drivers/xen/pvcalls-front.h
> index 25e05b8..3332978 100644
> --- a/drivers/xen/pvcalls-front.h
> +++ b/drivers/xen/pvcalls-front.h
> @@ -23,5 +23,6 @@ int pvcalls_front_recvmsg(struct socket *sock,
>  unsigned int pvcalls_front_poll(struct file *file,
>   struct socket *sock,
>   poll_table *wait);
> +int pvcalls_front_release(struct socket *sock);
>  
>

[Xen-devel] [ovmf test] 112644: all pass - PUSHED

flight 112644 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112644/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a6b3d753f98118ee547ae935b347f4f00fa67e7c
baseline version:
 ovmf 4ad5f597153c7cb20a968236c2c7d6ff01994350

Last test of basis   112636  2017-08-14 18:17:22 Z1 days
Testing same since   112644  2017-08-15 09:49:00 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



sg-report-flight on osstest.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=ovmf
+ revision=a6b3d753f98118ee547ae935b347f4f00fa67e7c
+ . ./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 ovmf 
a6b3d753f98118ee547ae935b347f4f00fa67e7c
+ branch=ovmf
+ revision=a6b3d753f98118ee547ae935b347f4f00fa67e7c
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' xa6b3d753f98118ee547ae935b347f4f00fa67e7c = 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
++ :

Re: [Xen-devel] [PATCH v3 11/13] xen/pvcalls: implement poll command

2017-08-15 Thread Boris Ostrovsky

On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> For active sockets, check the indexes and use the inflight_conn_req
> waitqueue to wait.
>
> For passive sockets if an accept is outstanding
> (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking
> at bedata->rsp[req_id]. If so, return POLLIN.  Otherwise use the
> inflight_accept_req waitqueue.
>
> If no accepts are inflight, send PVCALLS_POLL to the backend. If we have
> outstanding POLL requests awaiting for a response use the inflight_req
> waitqueue: inflight_req is awaken when a new response is received; on
> wakeup we check whether the POLL response is arrived by looking at the
> PVCALLS_FLAG_POLL_RET flag. We set the flag from
> pvcalls_front_event_handler, if the response was for a POLL command.
>
> In pvcalls_front_event_handler, get the struct sock_mapping from the
> poll id (we previously converted struct sock_mapping* to uint64_t and
> used it as id).
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 135 
> +---
>  drivers/xen/pvcalls-front.h |   3 +
>  2 files changed, 129 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 635a83a..1c975d6 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -72,6 +72,8 @@ struct sock_mapping {
>* Only one poll operation can be inflight for a given socket.
>*/
>  #define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
> +#define PVCALLS_FLAG_POLL_INFLIGHT   1
> +#define PVCALLS_FLAG_POLL_RET2
>   uint8_t flags;
>   uint32_t inflight_req_id;
>   struct sock_mapping *accept_map;
> @@ -139,15 +141,32 @@ static irqreturn_t pvcalls_front_event_handler(int irq, 
> void *dev_id)
>   rsp = RING_GET_RESPONSE(>ring, bedata->ring.rsp_cons);
>  
>   req_id = rsp->req_id;
> - dst = (uint8_t *)>rsp[req_id] + sizeof(rsp->req_id);
> - src = (uint8_t *)rsp + sizeof(rsp->req_id);
> - memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
> - /*
> -  * First copy the rest of the data, then req_id. It is
> -  * paired with the barrier when accessing bedata->rsp.
> -  */
> - smp_wmb();
> - WRITE_ONCE(bedata->rsp[req_id].req_id, rsp->req_id);
> + if (rsp->cmd == PVCALLS_POLL) {
> + struct sock_mapping *map = (struct sock_mapping *)
> +rsp->u.poll.id;
> +
> + set_bit(PVCALLS_FLAG_POLL_RET,
> + (void *)>passive.flags);
> + /*
> +  * Set RET, then clear INFLIGHT. It pairs with
> +  * the checks at the beginning of
> +  * pvcalls_front_poll_passive.
> +  */
> + smp_wmb();
> + clear_bit(PVCALLS_FLAG_POLL_INFLIGHT,
> +   (void *)>passive.flags);
> + } else {
> + dst = (uint8_t *)>rsp[req_id] +
> +   sizeof(rsp->req_id);
> + src = (uint8_t *)rsp + sizeof(rsp->req_id);
> + memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
> + /*
> +  * First copy the rest of the data, then req_id. It is
> +  * paired with the barrier when accessing bedata->rsp.
> +  */
> + smp_wmb();
> + WRITE_ONCE(bedata->rsp[req_id].req_id, rsp->req_id);
> + }
>  
>   done = 1;
>   bedata->ring.rsp_cons++;
> @@ -736,6 +755,104 @@ int pvcalls_front_accept(struct socket *sock, struct 
> socket *newsock, int flags)
>   return ret;
>  }
>  
> +static unsigned int pvcalls_front_poll_passive(struct file *file,
> +struct pvcalls_bedata *bedata,
> +struct sock_mapping *map,
> +poll_table *wait)
> +{
> + int notify, req_id, ret;
> + struct xen_pvcalls_request *req;
> +

I am a bit confused by the logic here.

> + if (test_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> +  (void *)>passive.flags)) {
> + uint32_t req_id = READ_ONCE(map->passive.inflight_req_id);
> + if (req_id != PVCALLS_INVALID_ID &&
> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id)
> + return POLLIN;

This is successful accept? Why is it returning POLLIN only and not
POLLIN | POLLRDNORM (or POLLOUT, for that matter)?

> +
> + poll_wait(file, >passive.inflight_accept_req, wait);
> +

[Xen-devel] [xtf test] 112645: all pass - PUSHED

flight 112645 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112645/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  24635d9265e70b2d75a17f2cfc0c2ca0fad5843b
baseline version:
 xtf  8956f82ce1321b89deda6895d58e5788d2198477

Last test of basis   112567  2017-08-10 18:47:47 Z5 days
Testing same since   112645  2017-08-15 10:46:41 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boqun Feng (Intel) 
  Boqun Feng 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=24635d9265e70b2d75a17f2cfc0c2ca0fad5843b
+ . ./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 xtf 
24635d9265e70b2d75a17f2cfc0c2ca0fad5843b
+ branch=xtf
+ revision=24635d9265e70b2d75a17f2cfc0c2ca0fad5843b
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x24635d9265e70b2d75a17f2cfc0c2ca0fad5843b = 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
++ :

Re: [Xen-devel] [PATCH for-2.10 v2 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

2017-08-15 Thread Michael S. Tsirkin

On Tue, Aug 15, 2017 at 02:07:51PM +0200, Igor Mammedov wrote:
> On Tue, 15 Aug 2017 12:15:48 +0100
> Anthony PERARD  wrote:
> 
> > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > set, but this was done only when ACPI tables are built which is not
> > needed for a Xen guest. The need for the property starts with commit
> > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > 
> > Set pci info before checking for the needs to build ACPI tables.
> > 
> > Assign bsel=0 property only to the root bus on Xen as there is no
> > support in the Xen ACPI tables for a different value.
> 
> looking at hw/acpi/pcihp.c and bsel usage there it looks like
> bsel property is owned by it and not by ACPI tables, so instead of
> shuffling it in acpi_setup(), how about moving bsel initialization
> to hw/acpi/pcihp.c and initialize it there unconditionally?
> 
> It could be as simple as moving acpi_set_pci_info()/acpi_set_bsel()
> there and calling it from acpi_pcihp_reset().
> 
> Then there won't be need for Xen specific branches, as root bus
> will have bsel set automatically which is sufficient for Xen and
> the rest of bsel-s (bridges) will be just unused by Xen,
> which could later extend its ACPI table implementation to utilize them. 

Later is exactly what I'd like to try to avoid.
Whoever wants acpi hotplug for bridges needs to get
the bsel info from qemu supplied acpi tables.

> 
> > Reported-by: Sander Eikelenboom 
> > Signed-off-by: Anthony PERARD 
> > 
> > ---
> > Changes in V2:
> >   - check for acpi_enabled before calling acpi_set_pci_info.
> >   - set the property on the root bus only.
> > 
> > This patch would be a canditade to backport to 2.9.
> > 
> > CC: Stefano Stabellini 
> > CC: Bruce Rogers 
> > ---
> >  hw/i386/acpi-build.c | 25 -
> >  1 file changed, 16 insertions(+), 9 deletions(-)
> > 
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index 98dd424678..c0483b96cf 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -46,6 +46,7 @@
> >  #include "sysemu/tpm_backend.h"
> >  #include "hw/timer/mc146818rtc_regs.h"
> >  #include "sysemu/numa.h"
> > +#include "hw/xen/xen.h"
> >  
> >  /* Supported chipsets: */
> >  #include "hw/acpi/piix4.h"
> > @@ -518,8 +519,13 @@ static void acpi_set_pci_info(void)
> >  unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
> >  
> >  if (bus) {
> > -/* Scan all PCI buses. Set property to enable acpi based hotplug. 
> > */
> > -pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, 
> > _alloc);
> > +if (xen_enabled()) {
> > +/* Assign BSEL property to root bus only. */
> > +acpi_set_bsel(bus, _alloc);
> > +} else {
> > +/* Scan all PCI buses. Set property to enable acpi based 
> > hotplug. */
> > +pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, 
> > _alloc);
> > +}
> >  }
> >  }
> >  
> > @@ -2871,6 +2877,14 @@ void acpi_setup(void)
> >  AcpiBuildState *build_state;
> >  Object *vmgenid_dev;
> >  
> > +if (!acpi_enabled) {
> > +ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n");
> > +return;
> > +}
> > +
> > +/* Assign BSEL property on hotpluggable PCI buses. */
> > +acpi_set_pci_info();
> > +
> >  if (!pcms->fw_cfg) {
> >  ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n");
> >  return;
> > @@ -2881,15 +2895,8 @@ void acpi_setup(void)
> >  return;
> >  }
> >  
> > -if (!acpi_enabled) {
> > -ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n");
> > -return;
> > -}
> > -
> >  build_state = g_malloc0(sizeof *build_state);
> >  
> > -acpi_set_pci_info();
> > -
> >  acpi_build_tables_init();
> >  acpi_build(, MACHINE(pcms));
> >  

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

[Xen-devel] [xen-unstable-smoke test] 112654: tolerable trouble: broken/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112651
 build-arm64   2 hosts-allocate  broken like 112651
 build-arm64-pvops 3 capture-logsbroken like 112651
 build-arm64   3 capture-logsbroken like 112651
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7591ea75f77643342b194031ef5a903564901ba8
baseline version:
 xen  6e2a4c73564ab907b732059adb317d6ca2d138a2

Last test of basis   112651  2017-08-15 14:01:21 Z0 days
Testing same since   112654  2017-08-15 17:01:16 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Julien Grall 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=7591ea75f77643342b194031ef5a903564901ba8
+ . ./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-smoke 
7591ea75f77643342b194031ef5a903564901ba8
+ branch=xen-unstable-smoke
+ revision=7591ea75f77643342b194031ef5a903564901ba8
+ . ./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-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x7591ea75f77643342b194031ef5a903564901ba8 = 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

[Xen-devel] [xen-unstable test] 112641: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   6 xen-install  fail REGR. vs. 112544
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112544
 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 112544
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 112544

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 112544

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112544
 build-arm64   2 hosts-allocate  broken like 112544
 build-arm64-xsm   3 capture-logsbroken like 112544
 build-arm64-pvops 2 hosts-allocate  broken like 112544
 build-arm64-pvops 3 capture-logsbroken like 112544
 build-arm64   3 capture-logsbroken like 112544
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112544
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112544
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112544
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112544
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112544
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112544
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112544
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  df8c142211b4559b136f377f58142214288fef8e
baseline version:
 xen

Re: [Xen-devel] [PATCH v8 07/13] arm/mem_access: Introduce GENMASK_ULL bit operation

2017-08-15 Thread Sergej Proskurin

Hi all,

On 08/09/2017 10:20 AM, Sergej Proskurin wrote:
> The current implementation of GENMASK is capable of creating bitmasks of
> 32-bit values on AArch32 and 64-bit values on AArch64. As we need to
> create masks for 64-bit values on AArch32 as well, in this commit we
> introduce the GENMASK_ULL bit operation. Please note that the
> GENMASK_ULL implementation has been lifted from the linux kernel source
> code.
> 

As all other patches of this patch series have been Acked, I would like
to friendly remind "The REST" maintainers to provide me with your
opinion/review on this particular patch. Thank you very much in advance :)

> Signed-off-by: Sergej Proskurin 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
> v6: As similar patches have been already submitted and NACKED in the
> past, we resubmit this patch with 'THE REST' maintainers in Cc to
> discuss whether this patch shall be applied into common or put into
> ARM related code.
> 
> v7: Change the introduced macro BITS_PER_LONG_LONG to BITS_PER_LLONG.
> 
> Define BITS_PER_LLONG also in asm-x86/config.h in order to allow
> global usage of the introduced macro GENMASK_ULL.
> 
> Remove previously unintended whitespace elimination in the function
> get_bitmask_order as it is not the right patch to address cleanup.
> ---
>  xen/include/asm-arm/config.h | 2 ++
>  xen/include/asm-x86/config.h | 2 ++
>  xen/include/xen/bitops.h | 3 +++
>  3 files changed, 7 insertions(+)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 5b6f3c985d..7da94698e1 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -19,6 +19,8 @@
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  #define POINTER_ALIGN BYTES_PER_LONG
>  
> +#define BITS_PER_LLONG 64
> +
>  /* xen_ulong_t is always 64 bits */
>  #define BITS_PER_XEN_ULONG 64
>  
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index bc0730fd9d..8b1de07dbc 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -15,6 +15,8 @@
>  #define BITS_PER_BYTE 8
>  #define POINTER_ALIGN BYTES_PER_LONG
>  
> +#define BITS_PER_LLONG 64
> +
>  #define BITS_PER_XEN_ULONG BITS_PER_LONG
>  
>  #define CONFIG_PAGING_ASSISTANCE 1
> diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
> index bd0883ab22..e2019b02a3 100644
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -10,6 +10,9 @@
>  #define GENMASK(h, l) \
>  (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
>  
> +#define GENMASK_ULL(h, l) \
> +(((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LLONG - 1 - (h
> +
>  /*
>   * ffs: find first bit set. This is defined the same way as
>   * the libc and compiler builtin ffs routines, therefore


Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v8 11/13] arm/mem_access: Add long-descriptor based gpt

2017-08-15 Thread Sergej Proskurin

Hi Julien,

On 08/15/2017 12:13 PM, Julien Grall wrote:
> 
> 
> On 14/08/17 22:03, Sergej Proskurin wrote:
>> Hi Julien,
>>
>> On 08/14/2017 07:37 PM, Julien Grall wrote:
>>> Hi Sergej,
>>>
>>> On 09/08/17 09:20, Sergej Proskurin wrote:
 +/*
 + * According to to ARM DDI 0487B.a J1-5927, we return an error if
 the found
>>>
>>> Please drop one of the 'to'. The rest looks good to me.
>>>
>>
>> Great, thanks. I will remove the second "to" in v9. Would that be an
>> Acked-by or shall I tag this patch with a Reviewed-by you?
> 
> Acked-by. FIY, you still missing an acked from "The REST" for patch #7,
> the rest looks fully acked.
> 

Yea, I know. I will ping The REST maintainers again.

Thanks,
~Sergej

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

Re: [Xen-devel] [PATCH 8/8] gnttab: drop struct active_grant_entry's gfn field for release builds

On 15/08/17 15:42, Jan Beulich wrote:
> This shrinks the size from 48 to 40 bytes bytes on 64-bit builds.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -185,7 +185,12 @@ struct active_grant_entry {
>  grant_ref_t   trans_gref;
>  struct domain *trans_domain;
>  unsigned long frame;  /* Frame being granted. */
> +#ifndef NDEBUG
>  unsigned long gfn;/* Guest's idea of the frame being granted. */
> +# define act_set_gfn(act, val) ((act)->gfn = (val))
> +#else
> +# define act_set_gfn(act, gfn)
> +#endif
>  spinlock_tlock;  /* lock to protect access of this entry.
>  see docs/misc/grant-tables.txt for
>  locking protocol  */

IMO, this would be cleaner as

static void act_set_gfn(struct active_grant_entry *act, unsigned long gfn)
{
#ifndef NDEBUG
act->gfn = gfn;
#endif
}

Which both moves the function out of the struct definition, and takes
care of side effect evaluation differences.

~Andrew

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

Re: [Xen-devel] [PATCH 7/8] gnttab: use DIV_ROUND_UP() instead of open-coding it

On 15/08/17 15:42, Jan Beulich wrote:
> Also adjust formatting of nearby code.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 6/8] gnttab: move GNTPIN_* out of header file

On 15/08/17 15:41, Jan Beulich wrote:
> They're private to grant_table.c.
>
> Signed-by: Jan Beulich 
>
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -158,7 +158,24 @@ shared_entry_header(struct grant_table *
>  
>  /* Active grant entry - used for shadowing GTF_permit_access grants. */
>  struct active_grant_entry {
> -uint32_t  pin;/* Reference count information. */
> +uint32_t  pin;/* Reference count information: */
> +  /* Count of writable host-CPU mappings. */
> +#define GNTPIN_hstw_shift(0)
> +#define GNTPIN_hstw_inc  (1 << GNTPIN_hstw_shift)
> +#define GNTPIN_hstw_mask (0xFFU << GNTPIN_hstw_shift)
> +  /* Count of read-only host-CPU mappings.*/
> +#define GNTPIN_hstr_shift(8)
> +#define GNTPIN_hstr_inc  (1 << GNTPIN_hstr_shift)
> +#define GNTPIN_hstr_mask (0xFFU << GNTPIN_hstr_shift)
> +  /* Count of writable device-bus mappings.   */
> +#define GNTPIN_devw_shift(16)
> +#define GNTPIN_devw_inc  (1 << GNTPIN_devw_shift)
> +#define GNTPIN_devw_mask (0xFFU << GNTPIN_devw_shift)
> +  /* Count of read-only device-bus mappings.  */
> +#define GNTPIN_devr_shift(24)
> +#define GNTPIN_devr_inc  (1 << GNTPIN_devr_shift)
> +#define GNTPIN_devr_mask (0xFFU << GNTPIN_devr_shift)

I would recommend taking the opportunity to switch these definitions to
1u << GNTPIN_*, as they are always used with unsigned types.

Either way, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 5/8] gnttab: re-arrange struct active_grant_entry

On 15/08/17 15:41, Jan Beulich wrote:
> While benign to 32-bit arches, this shrinks the size from 56 to 48
> bytes on 64-bit ones (while still leaving a 16-bit hole).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

There is some follow-on is_sub_page type cleanup you could do,
especially in acquire_grant_for_copy().

~Andrew

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

Re: [Xen-devel] [PATCH 4/8] gnttab: drop pointless leading double underscores

On 15/08/17 15:40, Jan Beulich wrote:
> They're violating name space rules, and we don't really need them. When
> followed by "gnttab_", also drop that.
>
> Signed-by: Jan Beulich 
>
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -233,8 +233,9 @@ static inline void active_entry_release(
> If rc == GNTST_okay, *page contains the page struct with a ref taken.
> Caller must do put_page(*page).
> If any error, *page = NULL, *frame = INVALID_MFN, no ref taken. */
> -static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct 
> page_info **page,
> -int readonly, struct domain *rd)
> +static int get_paged_frame(unsigned long gfn, unsigned long *frame,
> +   struct page_info **page, bool readonly,
> +   struct domain *rd)
>  {
>  int rc = GNTST_okay;
>  #if defined(P2M_PAGED_TYPES) || defined(P2M_SHARED_TYPES)
> @@ -300,7 +301,7 @@ double_gt_unlock(struct grant_table *lgt
>  #define INVALID_MAPTRACK_HANDLE UINT_MAX
>  
>  static inline grant_handle_t
> -__get_maptrack_handle(
> +_get_maptrack_handle(
>  struct grant_table *t,
>  struct vcpu *v)

Any chance of coalescent these parameters?  Theres no need for 4 lines
here, or in similar cases below.

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 3/8] gnttab: type adjustments

On 15/08/17 15:40, Jan Beulich wrote:
> In particular use grant_ref_t and grant_handle_t where appropriate.
> Also switch other nearby type uses to their canonical variants where
> appropriate and introduce INVALID_MAPTRACK_HANDLE.
>
> Signed-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

This needs rebasing over my change to simplify
gnttab_copy_lock_domain(), where I ended up with the same net change as
you've proposed.

~Andrew

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

Re: [Xen-devel] [PATCH RESEND 2/8] gnttab: avoid spurious maptrack handle allocation failures

On 15/08/17 15:39, Jan Beulich wrote:
> @@ -422,8 +422,13 @@ get_maptrack_handle(
>  /*
>   * If we've run out of frames, try stealing an entry from another
>   * VCPU (in case the guest isn't mapping across its VCPUs evenly).
> + * Also use this path in case we're out of memory, to avoid spurious
> + * failures.

This comment isn't strictly correct any more.  It is now "If we've run
out of handles and still have frame headroom, try allocating a new
maptrack frame.  If there is no headroom, or Xen is out of memory, try
stealing an entry from another vcpu".

~Andrew

>   */
> -if ( nr_maptrack_frames(lgt) >= max_maptrack_frames )
> +if ( nr_maptrack_frames(lgt) < max_maptrack_frames )
> +new_mt = alloc_xenheap_page();
> +
> +if ( !new_mt )
>  {
>  spin_unlock(>maptrack_lock);
>  


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

[Xen-devel] [linux-linus test] 112638: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13

Re: [Xen-devel] [PATCH RESEND 1/8] gnttab: drop useless locking