[Xen-devel] [xen-4.6-testing test] 101049: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 
101026
 test-amd64-i386-xl  19 guest-start/debian.repeat fail REGR. vs. 101026
 test-amd64-i386-xl-raw9 debian-di-installfail REGR. vs. 101026

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

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

version targeted for testing:
 xen  245fa11021f8f123a82aa7e894d044d8f0ae6923
baseline version:
 xen  57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a

Last test of basis   101026  2016-09-20 02:02:05 Z1 days
Testing same since   101049  2016-09-20 16:13:11 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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

[Xen-devel] [PATCH v4 1/6] VMX: Statically assign two PI hooks

[Feng Wu]

PI hooks: vmx_pi_switch_from() and vmx_pi_switch_to() are
needed even when any previously assigned device is detached
from the domain. Since 'SN' bit is also used to control the
CPU side PI and we change the state of SN bit in these two
functions, then evaluate this bit in vmx_deliver_posted_intr()
when trying to deliver the interrupt in posted way via software.
The problem is if we deassign the hooks while the vCPU is runnable
in the runqueue with 'SN' set, all the furture notificaton event
will be suppressed. This patch makes these two hooks statically
assigned.

Signed-off-by: Feng Wu 
---
v4:
- Don't zap vmx_pi_switch_from() and vmx_pi_switch_to() when
any previously assigned device is detached from the domain.
- Comments changes.

 xen/arch/x86/hvm/vmx/vmx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3d330b6..355936a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -221,8 +221,6 @@ void vmx_pi_hooks_deassign(struct domain *d)
 ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
 
 d->arch.hvm_domain.vmx.vcpu_block = NULL;
-d->arch.hvm_domain.vmx.pi_switch_from = NULL;
-d->arch.hvm_domain.vmx.pi_switch_to = NULL;
 d->arch.hvm_domain.vmx.pi_do_resume = NULL;
 }
 
-- 
2.1.0


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

[Xen-devel] [PATCH v4 2/6] VMX: Properly handle pi when all the assigned devices are removed

[Feng Wu]

This patch handles some concern cases when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again.
- No remaining vcpus of the domain in the per-cpu blocking list.

Basically, we pause the domain before zapping the PI hooks and
removing the vCPU from the blocking list, then unpause it after
that.

Signed-off-by: Feng Wu 
---
v4:
- Rename some functions:
vmx_pi_remove_vcpu_from_blocking_list() -> vmx_pi_list_remove()
vmx_pi_blocking_cleanup() -> vmx_pi_list_cleanup()
- Remove the check in vmx_pi_list_cleanup()
- Comments adjustment

 xen/arch/x86/hvm/vmx/vmx.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 355936a..7305f40 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -158,14 +158,12 @@ static void vmx_pi_switch_to(struct vcpu *v)
 pi_clear_sn(pi_desc);
 }
 
-static void vmx_pi_do_resume(struct vcpu *v)
+static void vmx_pi_list_remove(struct vcpu *v)
 {
 unsigned long flags;
 spinlock_t *pi_blocking_list_lock;
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
 
-ASSERT(!test_bit(_VPF_blocked, >pause_flags));
-
 /*
  * Set 'NV' field back to posted_intr_vector, so the
  * Posted-Interrupts can be delivered to the vCPU when
@@ -173,12 +171,12 @@ static void vmx_pi_do_resume(struct vcpu *v)
  */
 write_atomic(_desc->nv, posted_intr_vector);
 
-/* The vCPU is not on any blocking list. */
 pi_blocking_list_lock = v->arch.hvm_vmx.pi_blocking.lock;
 
 /* Prevent the compiler from eliminating the local variable.*/
 smp_rmb();
 
+/* The vCPU is not on any blocking list. */
 if ( pi_blocking_list_lock == NULL )
 return;
 
@@ -198,6 +196,18 @@ static void vmx_pi_do_resume(struct vcpu *v)
 spin_unlock_irqrestore(pi_blocking_list_lock, flags);
 }
 
+static void vmx_pi_do_resume(struct vcpu *v)
+{
+ASSERT(!test_bit(_VPF_blocked, >pause_flags));
+
+vmx_pi_list_remove(v);
+}
+
+static void vmx_pi_list_cleanup(struct vcpu *v)
+{
+vmx_pi_list_remove(v);
+}
+
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
@@ -215,13 +225,28 @@ void vmx_pi_hooks_assign(struct domain *d)
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_deassign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
 ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
 
+/*
+ * Pausing the domain can make sure the vCPU is not
+ * running and hence calling the hooks simultaneously
+ * when deassigning the PI hooks and removing the vCPU
+ * from the blocking list.
+ */
+domain_pause(d);
+
 d->arch.hvm_domain.vmx.vcpu_block = NULL;
 d->arch.hvm_domain.vmx.pi_do_resume = NULL;
+
+for_each_vcpu ( d, v )
+vmx_pi_list_cleanup(v);
+
+domain_unpause(d);
 }
 
 static int vmx_domain_initialise(struct domain *d)
-- 
2.1.0


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

[Xen-devel] [PATCH v4 3/6] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

[Feng Wu]

We should remove the vCPU from the per-cpu blocking list
if it is going to be destroyed.

Signed-off-by: Feng Wu 
---
v4:
- Call vmx_pi_list_cleanup() before vmx_destroy_vmcs()

 xen/arch/x86/hvm/vmx/vmx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7305f40..821cba2 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -336,6 +336,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
  * separately here.
  */
 vmx_vcpu_disable_pml(v);
+vmx_pi_list_cleanup(v);
 vmx_destroy_vmcs(v);
 vpmu_destroy(v);
 passive_domain_destroy(v);
-- 
2.1.0


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

[Xen-devel] [PATCH v4 5/6] VT-d: No need to set irq affinity for posted format IRTE

[Feng Wu]

We don't set the affinity for posted format IRTE, since the
destination of these interrupts is vCPU and the vCPU affinity
is set during vCPU scheduling.

Signed-off-by: Feng Wu 
---
v4:
- Keep the construction of new_ire and only modify the hardware
IRTE when it is not in posted mode.

 xen/drivers/passthrough/vtd/intremap.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c 
b/xen/drivers/passthrough/vtd/intremap.c
index bfd468b..4537714 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -637,9 +637,12 @@ static int msi_msg_to_remap_entry(
 remap_rte->address_hi = 0;
 remap_rte->data = index - i;
 
-memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
-iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
-iommu_flush_iec_index(iommu, 0, index);
+if ( !iremap_entry->remap.p || !iremap_entry->remap.im )
+{
+memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
+iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
+iommu_flush_iec_index(iommu, 0, index);
+}
 
 unmap_vtd_domain_page(iremap_entries);
 spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
-- 
2.1.0


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

[Xen-devel] [PATCH v4 6/6] VMX: Fixup PI descritpor when cpu is offline

[Feng Wu]

When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it.

Signed-off-by: Feng Wu 
---
v4:
- Remove the pointless check since we are in machine stop
context and no other cpus go down in parallel.

 xen/arch/x86/hvm/vmx/vmcs.c   |  1 +
 xen/arch/x86/hvm/vmx/vmx.c| 42 +++
 xen/include/asm-x86/hvm/vmx/vmx.h |  1 +
 3 files changed, 44 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index e733753..9f56c7c 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -578,6 +578,7 @@ void vmx_cpu_dead(unsigned int cpu)
 vmx_free_vmcs(per_cpu(vmxon_region, cpu));
 per_cpu(vmxon_region, cpu) = 0;
 nvmx_cpu_dead(cpu);
+vmx_pi_desc_fixup(cpu);
 }
 
 int vmx_cpu_up(void)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 09262d5..ff87444 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -208,6 +208,48 @@ static void vmx_pi_list_cleanup(struct vcpu *v)
 vmx_pi_list_remove(v);
 }
 
+void vmx_pi_desc_fixup(int cpu)
+{
+unsigned int new_cpu, dest;
+unsigned long flags;
+struct arch_vmx_struct *vmx, *tmp;
+spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
+struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
+
+if ( !iommu_intpost )
+return;
+
+spin_lock_irqsave(old_lock, flags);
+
+list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
+{
+/*
+ * We need to find an online cpu as the NDST of the PI descriptor, it
+ * doesn't matter whether it is within the cpupool of the domain or
+ * not. As long as it is online, the vCPU will be woken up once the
+ * notification event arrives.
+ */
+new_cpu = cpumask_any(_online_map);
+new_lock = _cpu(vmx_pi_blocking, new_cpu).lock;
+
+spin_lock(new_lock);
+
+ASSERT(vmx->pi_blocking.lock == old_lock);
+
+dest = cpu_physical_id(new_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_blocking.lock = new_lock;
+
+spin_unlock(new_lock);
+}
+
+spin_unlock_irqrestore(old_lock, flags);
+}
+
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 4cdd9b1..9783c70 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -569,6 +569,7 @@ void free_p2m_hap_data(struct p2m_domain *p2m);
 void p2m_init_hap_data(struct p2m_domain *p2m);
 
 void vmx_pi_per_cpu_init(unsigned int cpu);
+void vmx_pi_desc_fixup(int cpu);
 
 void vmx_pi_hooks_assign(struct domain *d);
 void vmx_pi_hooks_deassign(struct domain *d);
-- 
2.1.0


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

[Xen-devel] [PATCH v4 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list

[Feng Wu]

The current VT-d PI related code may operate incorrectly in the
following scenarios:
1. When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next time we attach another device to the domain,
which makes the PI realted hooks avaliable again, the status
of the pi descriptor is not true. Beside that, the blocking vcpu
may still remain in the per-cpu blocking in this case. Patch [1/6]
and [2/6] handle this.

2. After the domain is destroyed, the the blocking vcpu may also
remain in the per-cpu blocking. Handled in patch [3/6].

3. When IRTE is in posted mode, we don't need to set the irq
affinity for it, since the destination of these interrupts is
vCPU and the vCPU affinity is set during vCPU scheduling. Patch
[5/6] handles this.

4. When a pCPU is unplugged, and there might be vCPUs on its
list. Since the pCPU is offline, those vCPUs might not be woken
up again. [6/6] addresses it.

Feng Wu (6):
  VMX: Statically assign two PI hooks
  VMX: Properly handle pi when all the assigned devices are removed
  VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
  VMX: Make sure PI is in proper state before install the hooks
  VT-d: No need to set irq affinity for posted format IRTE
  VMX: Fixup PI descritpor when cpu is offline

 xen/arch/x86/hvm/vmx/vmcs.c|  14 ++---
 xen/arch/x86/hvm/vmx/vmx.c | 105 ++---
 xen/drivers/passthrough/vtd/intremap.c |   9 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |   1 +
 4 files changed, 111 insertions(+), 18 deletions(-)

-- 
2.1.0


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

[Xen-devel] [PATCH v4 4/6] VMX: Make sure PI is in proper state before install the hooks

[Feng Wu]

We may hit the ASSERT() in vmx_vcpu_block in the current code,
since vmx_vcpu_block() may get called before vmx_pi_switch_to()
has been installed or executed. Here We use cmpxchg to update
the NDST field, this can make sure we only update the NDST when
vmx_pi_switch_to() has not been called. So the NDST is in a
proper state in vmx_vcpu_block().

Suggested-by: Jan Beulich 
Signed-off-by: Feng Wu 
---
v4:
- This patch is previously called "Pause/Unpause the domain before/after 
assigning PI hooks"
- Remove the pause/unpause method
- Use cmpxchg to update NDST

 xen/arch/x86/hvm/vmx/vmcs.c | 13 +
 xen/arch/x86/hvm/vmx/vmx.c  | 27 ++-
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 1bd875a..e733753 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -956,16 +956,13 @@ void virtual_vmcs_vmwrite(const struct vcpu *v, u32 
vmcs_encoding, u64 val)
  */
 static void pi_desc_init(struct vcpu *v)
 {
-uint32_t dest;
-
 v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
 
-dest = cpu_physical_id(v->processor);
-
-if ( x2apic_enabled )
-v->arch.hvm_vmx.pi_desc.ndst = dest;
-else
-v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
+/*
+ * Mark NDST as invalid, then we can use this invalid value as a
+ * marker to whether update NDST or not in vmx_pi_hooks_assign().
+ */
+v->arch.hvm_vmx.pi_desc.ndst = 0xff;
 }
 
 static int construct_vmcs(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 821cba2..09262d5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -211,14 +211,39 @@ static void vmx_pi_list_cleanup(struct vcpu *v)
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
 ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
 
-d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
+/*
+ * We carefully handle the timing here:
+ * - Install the context switch first
+ * - Then set the NDST field
+ * - Install the block and resume hooks in the end
+ *
+ * This can make sure the PI (especially the NDST feild) is
+ * in proper state when we call vmx_vcpu_block().
+ */
 d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
 d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
+
+for_each_vcpu ( d, v )
+{
+unsigned int dest = cpu_physical_id(v->processor);
+struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
+
+   /*
+* We don't need to update NDST if 'arch.hvm_domain.vmx.pi_switch_to'
+* already gets called
+*/
+(void)cmpxchg(_desc->ndst, 0xff,
+x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK));
+}
+
+d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
 d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
 }
 
-- 
2.1.0


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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Lan Tianyu]

On 2016年09月20日 23:36, Jan Beulich wrote:
>> The precondition of process_pending_softirq() working in the debug key
>> > handler is that timer interrupt arrives on time and nmi_timer_fn() can
>> > run to update nmi_timer_ticks before watchdog timeout.
> Precondition?

Process_pending_softirq() in debug key handler is mainly to deal with
timer softirq to update nmi_timer_ticks in order to avoid NMI watchdog.
If there is no timer interrupt arriving for long time,
process_pending_softirq() here is meaningless and NMI watchdog still
will be timeout.

> 
>> > When a timer interrupt arrives, timer_softirq_action() will run all
>> > expired timer handlers before programing next timer interrupt via
>> > reprogram_timer(). If a timer handler runs too long E,G >5s(Time for
>> > watchdog timeout is default to be 5s.), this will cause no timer
>> > interrupt arriving within 5s and nmi_timer_fn() also won't be called.
>> > Does this make sense to you?
> Partly. I continue to think that the sequence
> 
> some keyhandler
>   timer interrupt
> keyhandler continues
> keyhandler calls process_pending_softirq()
> 

Question for your sequence is why there is timer interrupt before
programing timer interrupt.

Actually the sequence in this case is
timer interrupt
run key handlers in timer handler
program next timer interrupt
...



> should, among other things, result in timer_softirq_action() to get
> run. And I don't see the _timer_ handler running for to long here,
> only a key handler.

Key handler may run a long time(E,G >5s) on machine with amount of cpus
or create huge VM. If keyhandler doesn't run for long time,
timer_softirq_action() would also be not necessary since the default
timeout is 5s and nmi timer's interval is 1s.


> Are you perhaps instead suffering from the
> nested instance of timer_softirq_action() not being able to acquire
> its lock?

No, the serial port continues printing timer info before watchdog timeout.


-- 
Best regards
Tianyu Lan

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

[Xen-devel] [xen-4.5-testing test] 101045: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 100909
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100909
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100909
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100909
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100909

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

version targeted for testing:
 xen  e4ae4b03d35babc9624b7286f1ea4c6749bad84b
baseline version:
 xen  c18dfbb88670e9f2cabd93bbb32f661b71ffb73a

Last test of basis   100909  2016-09-13 02:09:03 Z7 days
Failing since101015  2016-09-19 16:13:24 Z1 days3 attempts
Testing same since   101045  2016-09-20 12:58:05 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 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
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   

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

[Dongli Zhang]

> > This patch implemented parts of TODO left in commit id
> > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush
> > filtering in alloc_heap_pages()). It moved TLB-flush filtering out into
> > populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow
> > to create a guest with memory size of more than 100GB on host with 100+
> > cpus.
> >
> >
> Do you have some actual numbers on how much faster after applying this
> patch?
> 
> This is mostly for writing release note etc, so it is fine if you don't
> have numbers at hand.

I do not have data of upstream version at hand now.  I always tested the
performance of this patchset by backporting it to an Oracle VM based on a
very old Xen version, before I sent out the patchset for review. The
backport just involves: (1) copy & paste code, (2) change bool to bool_t
and (3) change true/false to 1/0.

The test machine has 8 nodes of 2048GB memory and 128 cpu. With this
patchset applied, the time to re-create a VM (with 135GB memory and 12
vcpu) is reduced from 5min to 20s.

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

[Xen-devel] [xen-unstable test] 101040: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

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

Last test of basis   101008  2016-09-19 01:58:31 Z1 days
Failing since101012  2016-09-19 12:15:44 Z1 days3 attempts
Testing same since   101020  2016-09-19 20:28:16 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel Kiper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Olaf Hering 
  Paulina Szubarczyk 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Tamas K Lengyel 
  Wei Liu 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b6e89910dd31e38944900ddc5cb4b86cf25241b4
baseline version:
 ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2

Last test of basis67733  2016-09-20 11:46:17 Z0 days
Testing same since67735  2016-09-20 22:21:05 Z0 days1 attempts


People who touched revisions under test:
  Satya Yarlagadda 
  Star Zeng 
  Yonghong Zhu 

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 b6e89910dd31e38944900ddc5cb4b86cf25241b4
Author: Star Zeng 
Date:   Wed Aug 31 14:47:36 2016 +0800

MdeModulePkg PCD: Update PCD database structure definition to match 
BaseTools

To follow PI1.4a, BaseTools has be updated to fix artificial limitation of
SkuId range.

This patch is to update PCD database structure definition to match 
BaseTools.

Note: The source code and BaseTools need to be upgraded at the same time,
and if they are not upgraded at the same time, build error like below will
be triggered to help user identify the problem.

"Please make sure the version of PCD PEIM Service and the generated
PCD PEI Database match."

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Liming Gao 

commit a01f68bd9bd95d6cda2ddbe469d9e82e42726208
Author: Yonghong Zhu 
Date:   Thu Sep 1 14:36:24 2016 +0800

BaseTools: Follow PI1.4a to fix artificial limitation of PCD SkuId range

Current BaseTools follow previous PI spec to use UINT8 for SkuId, to
follow PI1.4a, BaseTools need to be updated to fix artificial limitation
of PCD SkuId range.

This patch is to update BaseTools to use UINT64 for SkuId, since the
PCD database structure needs to be naturally aligned, the PCD database
structure layout is adjusted to keep the natural alignment and version
is updated to 6.

Note: As the PCD database structure layout is adjusted, the structure
definition in MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h and
PCD drivers also need to be updated. That means the source code and
BaseTools need to be upgraded at the same time, and if they are not
upgraded at the same time, build error like below will be triggered
to help user identify the problem.

"Please make sure the version of PCD PEIM Service and the generated
PCD PEI Database match."

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit cd3692b11ed3c760acc1015ac19785b9a36054e8
Author: Satya Yarlagadda 
Date:   Sat Sep 17 11:24:49 2016 +0800

IntelFsp2Pkg: Align #Pragma in UPD header files to rest of EDK2 Pkgs

Changed the GenCfgOpt.py script to insert pragma pack(1) instead of
pragma pack (push, 1) in the upd header files generated during fsp build.
This is to align with rest of the EDKII pkgs pragma pack usage.

Also, this scripts generates UnusedUpdSpace for UPD address gaps.
Currently it uses UIN16/UINT32/UINT64 for 2/4/8 bytes instead of UINT8[],
thus causing upd space waste to have Natural Alignment. Hence changed the
script to use UINT8[] for any unusedUpd fields above 1 byte.

Cc: Maurice 

Re: [Xen-devel] boot-wrapped xen image barfs with overlapped sections

[Jun Sun]

I finally resolved this issue after hunting around.  The clue comes from
this page,
https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_ARM_Guide:

/chosen/module@1/reg should match bootwrapper model.lds.
>

Basically if I increase memory region for kernel, I should also update dts
file on  /chosen/module@1/reg.

Here is what in model.xen.lds.  As you can see, kernel area is increased to
14MB.

OUTPUT_FORMAT("elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
TARGET(binary)
INPUT(./boot.xen.o)
INPUT(Xen)
INPUT(Image)
INPUT(./fdt.dtb)
SECTIONS
{
 . = 0x8000;
 .text : { boot.xen.o }
 . = 0x8000 + 0xfff8;
 mbox = .;
 .mbox : { QUAD(0x0) }
 . = 0x8000 + 0xE0;
 xen = .;
 .xen : { Xen }
 . = 0x8000 + 0x8;
 kernel = .;
 .kernel : { Image }
 . = 0x8000 + 0x0800;
 dtb = .;
 .dtb : { ./fdt.dtb }
 .data : { *(.data) }
 .bss : { *(.bss) }
}

And here is what in foundation-v8.dts for chosen:

chosen {
#address-cells = <0x1>;
#size-cells = <0x1>;
xen,xen-bootargs = "dom0_mem=512M dom0_max_vcpus=2
dtuart=serial0 conswitch=x loglvl=all guest_loglvl=all no-bootscrub";

module@1 {
compatible = "xen,linux-zimage",
"xen,multiboot-module";
reg = <0x8008 0xe0>;
bootargs = "earlyprintk=pl011,0x1c09
console=hvc0 root=/dev/vda2 debug rw";
};
};

Kernels can be any recent 4.x kernel from torvalds, stable or linaro trees.

Now move to on to boot kernel with initrd.

Jun

On Fri, Sep 16, 2016 at 2:44 PM, Jun Sun  wrote:

>
> Hi, all,
>
> I have been following the instructions at https://wiki.linaro.org/
> LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation to build xen for
> arm64.
>
> When I tried to use the latest kernel instead of v3.13 as suggested, I
> failed when building boot-wrapped image.  See below.
>
> ===
> jsun@ubuntu:~/work/xen/linaro-2014-guide/boot-wrapper-aarch64$ make
> CROSS_COMPILE=aarch64-linux-gnu- FDT_SRC=foundation-v8.dts xen-system.axf
> aarch64-linux-gnu-ld -o xen-system.axf --script=model.xen.lds
> aarch64-linux-gnu-ld: section .xen loaded at 
> [80a0,80ac061f]
> overlaps section .kernel loaded at [8008,80c50dff]
> Makefile:78: recipe for target 'xen-system.axf' failed
> make: *** [xen-system.axf] Error 1
> ===
>
> Obviously the issue is that linker script gives about 8.5MB space for
> kernel which is too small. If I modify the linker script to give more space
> to kernel, the xen will halt during boot up right before Dom0 starts:
>
> ==
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 8008
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00a000-0x00c000 (512MB)
> (XEN) Grant table range: 0x00ffe0-0x00ffe5e000
> (XEN) Loading zImage from 8008 to a008-
> a088
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0xa800-0xa8000fe7
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
> to Xen)
> (XEN) Freed 276kB init memory.
> ==
>
> Any pointers on the right way to get modern kernel working with xen on
> ARM64?
>
> Thanks.
>
> Jun
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.6-testing baseline-only test] 67734: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67734 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67734/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-pvgrub 10 guest-start fail blocked in 67715
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail blocked in 67715
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 67715
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked 
in 67715
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-installfail blocked in 67715
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 67715
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67715

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-3   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-3  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-3   34 xtf/test-hvm64-invlpg~shadow fail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-1  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-1   34 xtf/test-hvm64-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-2  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-2   34 xtf/test-hvm64-invlpg~shadow fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a
baseline version:
 xen  3cffa34537767dfdb6a0fa02c1a54fdfc7644b6d

Last test of basis67715  2016-09-15 02:18:46 Z5 days
Testing same since67734  2016-09-20 15:45:31 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

[Lai, Paul]

On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote:
> 
> Paul, there's been no reply to
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html
> 
> Jan
> 

Jan:

The refered to patch, commit a1b1572833, adds a check for vmfunc.
I look a little time to look at the SDM and finally found the reference.
The vmfunc can be found in Table A-6 "Opcode Extensions for One- and Two-
byte Opcodes by Group Number" on page A-18 Vol. 2D of the
 e64-ia-32-architectures-software-developer-manual-325462.pdf.
The values for vmfunc match the values in the code.
I also took the liberty of looking at the other existing cases in the
switch statement, and can find RDTSCP and INVLPG. The CLZERO extension
value is a mystery to me.

I also tried to find the original email referred to by the URL above, but
could not in my mail archives.  Somehow it did not get to me, so I'm replying
to this email (with modified subject line) and Cc'ing Andy, Ravi, and xen-devel.

-Paul

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

[Xen-devel] [xen-4.5-testing bisection] complete build-i386

[osstest service owner]

branch xen-4.5-testing
xenbranch xen-4.5-testing
job build-i386
testid xen-build

Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  22857ab3492c35aac27691ae7184dcc935c5fb2a
  Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101068/


  commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
  Author: Jan Beulich 
  Date:   Mon Sep 19 17:50:59 2016 +0200
  
  update Xen version to 4.5.4


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.5-testing/build-i386.xen-build 
--summary-out=tmp/101068.bisection-summary --basis-template=100909 
--blessings=real,real-bisect xen-4.5-testing build-i386 xen-build
Searching for failure / basis pass:
 101024 fail [host=baroque1] / 100909 [host=pinot0] 100897 [host=pinot0] 100828 
[host=elbling0] 100814 [host=pinot0] 100769 ok.
Failure / basis pass flights: 101024 / 100769
(tree with no url: ovmf)
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
Basis pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
d50078b9f2d7df55157ca353d889b13a8f3f0bc6
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#835c204f1196ab8f5213a9dc5299ed76e748cdca-835c204f1196ab8f5213a9dc5299ed76e748cdca
 
git://xenbits.xen.org/xen.git#d50078b9f2d7df55157ca353d889b13a8f3f0bc6-22857ab3492c35aac27691ae7184dcc935c5fb2a
Loaded 1001 nodes in revision graph
Searching for test results:
 100769 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
d50078b9f2d7df55157ca353d889b13a8f3f0bc6
 100849 [host=baroque0]
 100814 [host=pinot0]
 100828 [host=elbling0]
 100897 [host=pinot0]
 100909 [host=pinot0]
 101015 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101065 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
 101066 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101067 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
 101052 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
d50078b9f2d7df55157ca353d889b13a8f3f0bc6
 101068 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101054 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101055 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
11c0462417051f56be0537c8cbf5973b2c648c2a
 101024 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101057 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
95559492c958e45fa7c01b1b3e0fb704e5b8b9eb
 101061 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
9edce7c42e6c2e8dd19788cab688cb46f779a9ec
 101063 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
 101064 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
Searching for interesting versions
 Result found: flight 100769 (pass), for basis pass
 Result found: flight 101015 (fail), for basis failure
 Repro found: flight 101052 (pass), for basis pass
 Repro found: flight 101054 (fail), for basis failure
 0 revisions at 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
No revisions left to test, checking graph state.
 Result found: flight 101063 (pass), for last pass
 Result found: flight 101064 (fail), for first failure
 Repro found: flight 101065 (pass), for last pass
 Repro found: flight 101066 (fail), for first failure
 Repro found: flight 101067 (pass), for last pass
 Repro found: flight 101068 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  22857ab3492c35aac27691ae7184dcc935c5fb2a
  Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101068/


  commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
  Author: Jan Beulich 
  Date:   Mon Sep 19 17:50:59 2016 +0200
  
  update Xen version to 4.5.4

Revision graph left in 
/home/logs/results/bisect/xen-4.5-testing/build-i386.xen-build.{dot,ps,png,html,svg}.

101068: tolerable ALL FAIL

flight 101068 xen-4.5-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/101068/

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b6e89910dd31e38944900ddc5cb4b86cf25241b4
baseline version:
 ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2

Last test of basis   101025  2016-09-20 01:49:01 Z0 days
Testing same since   101043  2016-09-20 11:51:49 Z0 days1 attempts


People who touched revisions under test:
  Satya Yarlagadda 
  Star Zeng 
  Yonghong Zhu 

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=b6e89910dd31e38944900ddc5cb4b86cf25241b4
+ . ./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 
b6e89910dd31e38944900ddc5cb4b86cf25241b4
+ branch=ovmf
+ revision=b6e89910dd31e38944900ddc5cb4b86cf25241b4
+ . ./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.7-testing
+ '[' xb6e89910dd31e38944900ddc5cb4b86cf25241b4 = 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
++ : 

[Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

[Chris Patterson]

From: Chris Patterson 

xs_watch() creates a thread to listen to xenstore events.  Currently, the
thread is created with the greater of 16K or PTHREAD_MIN_SIZE.

There have been several bug reports and workarounds related to the issue
where xs_watch() fails because its attempt to create the reader thread with
pthread_create() fails. This is due to insufficient stack space size
given the requirements for thread-local storage usage in the applications
and libraries that are linked against libxenstore.  [1,2,3,4].

Specifying the stack size appears to have been added to reduce memory
footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).

This has already been bumped up once to the greater of 16k and
PTHREAD_STACK_MIN (da6a0e86d6a079102abdd0858a19f1e1fae584fc).

This patch reverts to sticking with the system's default stack size and
removes the code used to set the thread's stack size.

Of course, the alternative is to bump it to another arbitrary value, but the
requirements may change depending on the application and its libraries that
are linking against xenstore.

[1] https://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg03341.html
[2] https://lists.xenproject.org/archives/html/xen-users/2016-07/msg00012.html
[3] https://lists.xenproject.org/archives/html/xen-users/2016-07/msg00085.html
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1350264

Signed-off-by: Chris Patterson 
---
 tools/xenstore/xs.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index d1e01ba..c62b120 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -723,11 +723,6 @@ bool xs_watch(struct xs_handle *h, const char *path, const 
char *token)
struct iovec iov[2];
 
 #ifdef USE_PTHREAD
-#define DEFAULT_THREAD_STACKSIZE (16 * 1024)
-#define READ_THREAD_STACKSIZE  \
-   ((DEFAULT_THREAD_STACKSIZE < PTHREAD_STACK_MIN) ?   \
-   PTHREAD_STACK_MIN : DEFAULT_THREAD_STACKSIZE)
-
/* We dynamically create a reader thread on demand. */
mutex_lock(>request_mutex);
if (!h->read_thr_exists) {
@@ -738,11 +733,6 @@ bool xs_watch(struct xs_handle *h, const char *path, const 
char *token)
mutex_unlock(>request_mutex);
return false;
}
-   if (pthread_attr_setstacksize(, READ_THREAD_STACKSIZE) != 
0) {
-   pthread_attr_destroy();
-   mutex_unlock(>request_mutex);
-   return false;
-   }
 
sigfillset();
pthread_sigmask(SIG_SETMASK, , _set);
-- 
2.1.4


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

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

[Stefano Stabellini]

On Tue, 20 Sep 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 20/09/2016 20:09, Stefano Stabellini wrote:
> > On Tue, 20 Sep 2016, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 20/09/2016 12:27, George Dunlap wrote:
> > > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan 
> > > > wrote:
> > > > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
> > > > > > On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
> > > > > > > On Tue, 20 Sep 2016, Dario Faggioli wrote:
> > > > > I'd like to add a computing capability in xen/arm, like this:
> > > > > 
> > > > > struct compute_capatiliby
> > > > > {
> > > > >char *core_name;
> > > > >uint32_t rank;
> > > > >uint32_t cpu_partnum;
> > > > > };
> > > > > 
> > > > > struct compute_capatiliby cc=
> > > > > {
> > > > >   {"A72", 4, 0xd08},
> > > > >   {"A57", 3, 0},
> > > > >   {"A53", 2, 0xd03},
> > > > >   {"A35", 1, ...},
> > > > > }
> > > > > 
> > > > > Then when identify cpu, we decide which cpu is big and which cpu is
> > > > > little
> > > > > according to the computing rank.
> > > > > 
> > > > > Any comments?
> > > > 
> > > > I think we definitely need to have Xen have some kind of idea the
> > > > order between processors, so that the user doesn't need to figure out
> > > > which class / pool is big and which pool is LITTLE.  Whether this sort
> > > > of enumeration is the best way to do that I'll let Julien and Stefano
> > > > give their opinion.
> > > 
> > > I don't think an hardcoded list of processor in Xen is the right solution.
> > > There are many existing processors and combinations for big.LITTLE so it
> > > will
> > > nearly be impossible to keep updated.
> > > 
> > > I would expect the firmware table (device tree, ACPI) to provide relevant
> > > data
> > > for each processor and differentiate big from LITTLE core.
> > > Note that I haven't looked at it for now. A good place to start is looking
> > > at
> > > how Linux does.
> > 
> > That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It is
> > trivial to identify the two different CPU classes and which cores belong
> > to which class.t, as
> 
> The class of the CPU can be found from the MIDR, there is no need to use the
> device tree/acpi for that. Note that I don't think there is an easy way in
> ACPI (i.e not in AML) to find out the class.
> 
> > It is harder to figure out which one is supposed to be
> > big and which one LITTLE. Regardless, we could default to using the
> > first cluster (usually big), which is also the cluster of the boot cpu,
> > and utilize the second cluster only when the user demands it.
> 
> Why do you think the boot CPU will usually be a big one? In the case of Juno
> platform it is configurable, and the boot CPU is a little core on r2 by
> default.
> 
> In any case, what we care about is differentiate between two set of CPUs. I
> don't think Xen should care about migrating a guest vCPU between big and
> LITTLE cpus. So I am not sure why we would want to know that.

No, it is not about migrating (at least yet). It is about giving useful
information to the user. It would be nice if the user had to choose
between "big" and "LITTLE" rather than "class 0x1" and "class 0x100", or
even "A7" or "A15".

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

[Xen-devel] [xen-unstable-smoke test] 101056: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
baseline version:
 xen  8fec44f23cf59d9be02df055b40e9f9536a0d570

Last test of basis   101047  2016-09-20 14:02:30 Z0 days
Testing same since   101056  2016-09-20 18:03:25 Z0 days1 attempts


People who touched revisions under test:
  Dongli Zhang 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
+ . ./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 
a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
+ branch=xen-unstable-smoke
+ revision=a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
+ . ./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.7-testing
+ '[' xa9c9600bb5b2f79058ce24f0ef51f22c78e89ba1 = 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
++ : 

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

[Julien Grall]

Hi Stefano,

On 20/09/2016 20:09, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Julien Grall wrote:

Hi,

On 20/09/2016 12:27, George Dunlap wrote:

On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan  wrote:

On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:

On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Dario Faggioli wrote:

I'd like to add a computing capability in xen/arm, like this:

struct compute_capatiliby
{
   char *core_name;
   uint32_t rank;
   uint32_t cpu_partnum;
};

struct compute_capatiliby cc=
{
  {"A72", 4, 0xd08},
  {"A57", 3, 0},
  {"A53", 2, 0xd03},
  {"A35", 1, ...},
}

Then when identify cpu, we decide which cpu is big and which cpu is little
according to the computing rank.

Any comments?


I think we definitely need to have Xen have some kind of idea the
order between processors, so that the user doesn't need to figure out
which class / pool is big and which pool is LITTLE.  Whether this sort
of enumeration is the best way to do that I'll let Julien and Stefano
give their opinion.


I don't think an hardcoded list of processor in Xen is the right solution.
There are many existing processors and combinations for big.LITTLE so it will
nearly be impossible to keep updated.

I would expect the firmware table (device tree, ACPI) to provide relevant data
for each processor and differentiate big from LITTLE core.
Note that I haven't looked at it for now. A good place to start is looking at
how Linux does.


That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It is
trivial to identify the two different CPU classes and which cores belong
to which class.t, as


The class of the CPU can be found from the MIDR, there is no need to use 
the device tree/acpi for that. Note that I don't think there is an easy 
way in ACPI (i.e not in AML) to find out the class.



It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot cpu,
and utilize the second cluster only when the user demands it.


Why do you think the boot CPU will usually be a big one? In the case of 
Juno platform it is configurable, and the boot CPU is a little core on 
r2 by default.


In any case, what we care about is differentiate between two set of 
CPUs. I don't think Xen should care about migrating a guest vCPU between 
big and LITTLE cpus. So I am not sure why we would want to know that.


The only thing we need an identifier for each set (I might be the MIDR 
or the compatible in the device tree).


Note that, as Peng mentioned, Linaro is working on an energy-aware 
scheduler. So there is a way (maybe not yet upstreamed) to find the CPU 
topology.


Regards,

--
Julien Grall

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

[Xen-devel] [qemu-mainline test] 101032: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   3 host-install(3)broken REGR. vs. 101017

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101017
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101017
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101017

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

version targeted for testing:
 qemuu33e1666b4289313306371fee0740f5c85517e406
baseline version:
 qemuu3d47a1390bd80b7b974185827a340012d21ad1e3

Last test of basis   101017  2016-09-19 17:22:00 Z1 days
Testing same since   101032  2016-09-20 05:57:15 Z0 days1 attempts


People who touched revisions under test:
  Marc-André Lureau 
  Markus Armbruster 
  Peter Maydell 

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

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

[Stefano Stabellini]

On Tue, 20 Sep 2016, Julien Grall wrote:
> Hi,
> 
> On 20/09/2016 12:27, George Dunlap wrote:
> > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan  wrote:
> > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
> > > > On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
> > > > > On Tue, 20 Sep 2016, Dario Faggioli wrote:
> > > I'd like to add a computing capability in xen/arm, like this:
> > > 
> > > struct compute_capatiliby
> > > {
> > >char *core_name;
> > >uint32_t rank;
> > >uint32_t cpu_partnum;
> > > };
> > > 
> > > struct compute_capatiliby cc=
> > > {
> > >   {"A72", 4, 0xd08},
> > >   {"A57", 3, 0},
> > >   {"A53", 2, 0xd03},
> > >   {"A35", 1, ...},
> > > }
> > > 
> > > Then when identify cpu, we decide which cpu is big and which cpu is little
> > > according to the computing rank.
> > > 
> > > Any comments?
> > 
> > I think we definitely need to have Xen have some kind of idea the
> > order between processors, so that the user doesn't need to figure out
> > which class / pool is big and which pool is LITTLE.  Whether this sort
> > of enumeration is the best way to do that I'll let Julien and Stefano
> > give their opinion.
> 
> I don't think an hardcoded list of processor in Xen is the right solution.
> There are many existing processors and combinations for big.LITTLE so it will
> nearly be impossible to keep updated.
> 
> I would expect the firmware table (device tree, ACPI) to provide relevant data
> for each processor and differentiate big from LITTLE core.
> Note that I haven't looked at it for now. A good place to start is looking at
> how Linux does.

That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It is
trivial to identify the two different CPU classes and which cores belong
to which class. It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot cpu,
and utilize the second cluster only when the user demands it.

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

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

[Lars Kurth]

On 20/09/2016 18:01, "Ian Jackson"  wrote:

>Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision
>making; some new roles and minor changes"):
>> [proposal]
>
>Thanks.  I've reviewed this and it looks generally good but I have
>some specific comments.
>
>
>Throughout you use "gage" where I think you should use "gauge".
>(AFAICT from Wiktionary this is not a US/UK spelling thing.)

Will fix.


>> +Voting is conducted in line with the following rules:
>> +
>> +-   Project leadership team members vote for (**+1**) or against
>>(**-1**) a 
>> +resolution. There is no differentiation between **+1**/ **+2** and
>> +**-1**/**-2**: in other words a **+2** is counted as a vote for, a
>>**-2** as a 
>> +vote against the resolution. The number of votes for and against a
>>resolution 
>> +is called **active vote**. **0** votes **are not counted** as an
>>active vote.
>> +-   A **quorum of more than 50% of active votes** is required for a
>>resolution 
>> +to pass. In other words, if the leadership team has 7 members, at
>>least 4 
>> +active votes are required for a resolution to pass.
>> +-   The resolution passes, if a 2/3 majority of active votes is in
>>favour of 
>> +it. 
>
>Quorums like this should count only positive votes.  Otherwise someone
>who opposes a proposal has to guess whether it is more likely to fail
>quorum, or to fail the 2/3 majority.  If it is likely to fail quorum,
>they should refrain from voting.

I think probably the term quorum is leading to some confusion here and
should probably be changed. Basically what

+-   A **quorum of more than 50% of active votes** is required for a
resolution 
+to pass. In other words, if the leadership team has 7 members, at least 4
+active votes are required for a resolution to pass.


is trying to encode is a turnout threshold of >50% (discounting spoilt
ballot papers: in other words a **0** votes would be the equivalent of a
spoilt ballot paper). My thinking was that
A) The rules would encourage team members to vote for or against a
proposal, rather than abstain
B) The minimum threshold is there to ensure that we don't have to manage
disappearing leadership team members tightly and that decisions have
enough legitimacy
C) The 2/3 majority would only apply to the people that have voted for or
against a proposal

>For example with a team of 6, with two people having alread voted yes,
>and the remaining three having expressly declined to vote because they
>don't have an opinion, a leadership team member who votes "no" would
>move the outcome from "quorum not met since only 2 out of 6 active
>voters - fail" to "quorum met with 3 active voters, 2 votes in favour,
>one against, 2/3 majority met - pass".

This is wrong. With a team of 6, at least 4 people would need to vote
"yes" or "no" to pass the 50% threshold. If more than "2" decline to vote,
the threshold wont be achieved. Amongst the 4 votes, 3 would need to be in
favour.

But you are right, this does open the door to tactical voting in some
boundary cases. So if there were 2 active "0" votes and 3 "+1" votes, the
last voter could shoot down the proposal by voting "0". If the vote had
been secret, that person would probably vote "-1" and the proposal would
pass. The same applies, if we were close to the voting deadline and 3
people had voted "+1" and 2 had not.

I am not quite sure I understand what you mean by "otherwise someone who
opposes a proposal has to guess whether it is more likely to fail quorum,
or to fail the 2/3 majority", but I guess it is what I outlined above. I
suppose the whole issue would go away, if there was a secret vote. But
introducing this, would be a bit heavyweight.
 
>I suggest changing the quorum threshold to count only explicit
>abstentions and votes in favour; either 1/3 or 50% would do.

I am not suggesting this is a bad idea, but I don't think I fully
understand what you mean and how your proposal avoids the issue above.

>> -### Conflict Resolution
>> +Let me express this as an algorithm.
>>  
>> -
>>-
>>
>> -ISSUES TO BE ADDRESSED LATER:
>> -- Generalise refereeing in terms of Project Leadership instead of
>>specific roles
>> -- Also some examples for sPecific situations that have happened in
>>the past may be 
>> -  useful
>> -
>>-
>>
>> +  treshhold=2/3;
>
> threshold
>
>> +  active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>
> ^
>   at the time of
>writing, 2016-09-20
>
>> - Refereeing
>> +One open question is what to do with 0-votes. We could introduce a
>>rule discounting 
>> +0 votes (let's call it 0-rule). If someone votes 0, we assume they
>>really 

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Daniel Kiper]

On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 12:52,  wrote:
> > On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
> >> >>> On 20.09.16 at 11:45,  wrote:
> >> > On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
> >> >> >>> On 19.09.16 at 17:04,  wrote:
> >> >> > On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 12.09.16 at 22:18,  wrote:
> >> >> >> > --- a/xen/arch/x86/setup.c
> >> >> >> > +++ b/xen/arch/x86/setup.c
> >> >> >> > @@ -520,6 +520,8 @@ static void noinline init_done(void)
> >> >> >> >
> >> >> >> >  system_state = SYS_STATE_active;
> >> >> >> >
> >> >> >> > +free_ebmalloc_unused_mem();
> >> >> >>
> >> >> >> Now that the allocator properly lives in common code, this appears
> >> >> >> to lack an ARM side counterpart.
> >> >> >
> >> >> > Why? It is called only from xen/arch/x86/setup.c:__start_xen() and all
> >> >> > ebmalloc stuff is in #ifndef CONFIG_ARM. So, 
> >> >> > free_ebmalloc_unused_mem()
> >> >> > will be needed only if we add ARM support here.
> >> >>
> >> >> Well, it being inside that conditional is part of the problem - there's
> >> >> no apparent point for all of it to be.
> >> >
> >> > I can agree that this is potentially generic stuff (well, I understand 
> >> > that
> >> > it is our final goal but unreachable yet due to various things). However,
> >> > right know it is only used on x86. So, I am not sure what is the problem
> >> > with #ifndef CONFIG_ARM right now...
> >>
> >> It is a fact that these should actually not be there, so we ought to
> >> at least limit them to the smallest possible count and scopes.
> >>
> >> >> Arguably the one static function may better be, as other workarounds
> >> >> to avoid the "unused" compiler warning wouldn't be any better.
> >> >
> >> > Do you mean static function with empty body for ARM? It is not needed
> >> > right now because it is never called on ARM. Am I missing something?
> >>
> >> You misunderstood - I said that for this one (unused) static
> >> function such an #ifdef is probably okay, as the presumably
> >> smallest possible workaround.
> >
> > Do you suggest that I should move out of #ifndef CONFIG_ARM all ebmalloc 
> > stuff
> > except free_ebmalloc_unused_mem(). Even if it is not used on ARM right now?
>
> That's not the static function, is it? The function you name should
> actually be called on ARM too (as I did point out elsewhere already),
> just to not leave a trap open for someone to fall into when (s)he
> adds a first use of the allocator on ARM.

Well, I think that sane person doing that would analyze how ebmalloc works
on x86 and then move (align to ARM needs if required) all its machinery
(including free_ebmalloc_unused_mem()) to run on ARM. At least I would do
that. This way he/she would avoid issues mentioned by you. However, if you
still prefer your way I can do that. Though I am not sure about the rest of
ebmalloc stuff. Should I move it out of #ifndef CONFIG_ARM? Looking at your
earlier replies I see that yes. Am I correct?

> >> >> >> > +static unsigned long __initdata ebmalloc_allocated;
> >> >> >> > +
> >> >> >> > +/* EFI boot allocator. */
> >> >> >> > +static void __init *ebmalloc(size_t size)
> >> >> >> > +{
> >> >> >> > +void *ptr = ebmalloc_mem + ebmalloc_allocated;
> >> >> >> > +
> >> >> >> > +ebmalloc_allocated += (size + sizeof(void *) - 1) & 
> >> >> >> > ~((typeof(size))sizeof(void *) - 1);
> >> >> >>
> >> >> >> What's the point of this ugly cast?
> >> >> >
> >> >> > In general ALIGN_UP() would be nice here. However, there is no such 
> >> >> > thing
> >> >> > in Xen headers (or I cannot find it). Should I add one? As separate 
> >> >> > patch?
> >> >>
> >> >> I understand what you want the expression for, but you didn't
> >> >> answer my question. Or do you not realize that all this cast is
> >> >> about is a strange way of converting an expression of type
> >> >> size_t to type size_t?
> >> >
> >> > Does sizeof() returns size_t type? I was thinking that it returns
> >> > a number calculated during compilation, however, it does not have
> >> > specific type.
> >>
> >> Every expression needs to have a well specified type. Even
> >> plain numbers do.
> >
> > Hmmm... So, what is a type e.g. 5 without "U" and/or "L"? int?
>
> Of course. But please may I ask you to read the spec instead?

Thanks! Sure thing!

Daniel

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

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

[Daniel Kiper]

On Tue, Sep 20, 2016 at 07:23:06AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 14:11,  wrote:
> > On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote:
> >> >>> On 14.09.16 at 10:23,  wrote:
> >> > Additionally, my investigation has shown that there are no bound checks 
> >> > in
> >> > low memory allocation machinery for trampoline (by the way, in BIOS path 
> >> > we
> >> > allocate 64 KiB for trampoline but in EFI code we properly calculate its 
> >> > size;
> >> > so, I think we should do the same calculation in BIOS path), stack and 
> >> > boot data
> >> > taken from multiboot protocol. Hence, relevant fixes should be added 
> >> > here too.
> >>
> >> Would be nice, yes, but we need to weigh the need to presumably do
> >> at least some of this in assembly code (for now at least) against the
> >> potential gain.
> >>
> >> > Moreover I think that at least allocation machinery with additional 
> >> > checks
> >> > described in last paragraph can be used on EFI platforms when Xen is 
> >> > booted
> >> > via multiboot2 protocol. However, then high limit should be defined as 1 
> >> > MiB.
> >> > Though I think that low limit, 256 KiB, should stay as is.
> >>
> >> Why 1Mb? The 640k limit derives from hardware aspects, but doesn't
> >> depend on the software environment.
> >
> > I do not expect that anything which is not memory will reside between 640 
> > KiB
> > and 1 MiB on EFI platforms. So, if firmware says that it is usable why we 
> > cannot
> > use it? And I have a feeling that this idea lead to currently existing 
> > checks
> > around trampoline allocation code for EFI. Though, as I saw EFI platforms
> > usually does not expose region 640 KiB and 1 MiB as usable. However, this
> > does not mean that they cannot in the future.
>
> Hmm, when the region (or part of it) is reported as available, then I
> guess we could use it. But as to there being RAM - I doubt it, since
> for the next little while, EFI or not, we're talking about PC compatible
> systems, which don't normally have RAM in that range.

If we drop BIOS and move to EFI then compatibility with PC drops to tiny
fraction of original platform. So, in this context lack of VGA or anything
like that above 640 KiB is not an issue IMO and memory there would not be
very big surprise for me. However, if you care I would ask why do you use
1 MiB limit instead of 640 KiB in xen/arch/x86/efi/efi-boot.h? I do not
say this is huge mistake but I am curious why not 640 KiB? I suppose that
there was a reason for it but I cannot find anything about that in comments
or commit messages.

Daniel

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

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

[Daniel Kiper]

On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 15:56,  wrote:
> > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote:

[...]

> >> So before taking this patch I'd really like to see proof that what gets
> >> done currently does actually go wrong in at least one case. So far I
> >
> > During initial work on this patch series I discovered that p_memsz in xen
> > ELF file is set to unreasonably huge value, IIRC, ~1 GiB. That is why at
> > first I enforced 16 MiB here (just temporary workaround) and later proposed
> > this patch. Sadly, right now I am not able to find commit which introduced
> > this issue. However, it seems that it was "fixed" later by another commit.
> >
> > Anyway, I am not sure why are you against, IMO, more reliable solution.
> > This way we would avoid in the future similar issues which I described
> > above.
>
> I'm not against anything if it gets properly explained. Here,
> however, you present some vague statements which even you
> can't verify right now as it looks.

OK, I did some more tests and found out that after patch "efi: build
xen.gz with EFI code" we have following xen ELF file:

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz Flg Align
  LOAD   0x80 0x0010 0x0010 0x20c120 0x3ff0 RWE 0x40
 ^^

because "nm -nr xen/xen-syms" emits:

82d0c000 A ALT_START
82d08034d000 A __2M_rwdata_end
82d08034cc00 A _end
82d08034cc00 B __per_cpu_data_end
82d08034cc00 B __bss_end

[...]

ALT_START lives in xen/arch/x86/efi/relocs-dummy.S. relocs-dummy.S
provides __base_relocs_start and __base_relocs_end symbols which
are referenced in xen/arch/x86/efi/efi-boot.h:efi_arch_relocate_image().
Of course one can argue that maybe we should do some changes in
efi_arch_relocate_image() and/or xen/arch/x86/efi/relocs-dummy.S.
This is true. However, this is separate issue and we should consider
it as such.

"efi: build xen.gz with EFI code" patch clearly shows that current
method used to calculate  mkelf32 argument is based
on bogus assumptions and very fragile. So, IMO, it should be changed
to something which is more reliable. And my proposal looks quite good.

Daniel

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

[Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

Hi all,
I'm trying to figure out the design decision regarding the handling of
guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
(vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
TLB utilization point-of-view this seems to be rather wasteful.
Furthermore, it even breaks the guests' ability to take advantage of
PCID, as the TLB just guts flushed when a new process is scheduled.
Does anyone have an insight into what was the rationale behind this?

Thanks,
Tamas

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

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

[Dario Faggioli]

On Tue, 2016-09-20 at 17:34 +0200, Julien Grall wrote:
> On 20/09/2016 12:27, George Dunlap wrote:
> > I think we definitely need to have Xen have some kind of idea the
> > order between processors, so that the user doesn't need to figure
> > out
> > which class / pool is big and which pool is LITTLE.  Whether this
> > sort
> > of enumeration is the best way to do that I'll let Julien and
> > Stefano
> > give their opinion.
> 
> I don't think an hardcoded list of processor in Xen is the right 
> solution. There are many existing processors and combinations for 
> big.LITTLE so it will nearly be impossible to keep updated.
> 
As far as either the scheduler or cpupools go, what's necessary would
be:
 - in Xen, a function (or an array acting as a map, or whatever) to 
   call to know whether pcpu X is big or LITTLE;
 - at toolstack level, an hypercal (or a field, bit, whatever in a
   struct already returned by an existing hypercall) to know the same 
   thing, i.e., whether c pcpu is big or LITTLE.

Once we have this, we can do everything. We will probably want to
abstract things a bit, and make them as generic as practical, so that
the same interface can be used not only for ARM big.LITTLE, but for
whatever future heterogeneous cpu arch we'll support... but really, the
actual information that we need is "just" that.

I've absolutely no idea how such info could be achieved, and I have no
ARM big.LITTLE hardware to test on.

> I would expect the firmware table (device tree, ACPI) to provide 
> relevant data for each processor and differentiate big from LITTLE
> core.
> Note that I haven't looked at it for now. A good place to start is 
> looking at how Linux does.
> 
Makes sense.

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

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 101047: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  8fec44f23cf59d9be02df055b40e9f9536a0d570
baseline version:
 xen  f1446de4ba5218a58fa2486ebe090495e0fb05c4

Last test of basis   101018  2016-09-19 18:02:42 Z0 days
Testing same since   101047  2016-09-20 14:02:30 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=8fec44f23cf59d9be02df055b40e9f9536a0d570
+ . ./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 
8fec44f23cf59d9be02df055b40e9f9536a0d570
+ branch=xen-unstable-smoke
+ revision=8fec44f23cf59d9be02df055b40e9f9536a0d570
+ . ./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.7-testing
+ '[' x8fec44f23cf59d9be02df055b40e9f9536a0d570 = 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
++ : 

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

[Ian Jackson]

Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision making; some 
new roles and minor changes"):
> [proposal]

Thanks.  I've reviewed this and it looks generally good but I have
some specific comments.


Throughout you use "gage" where I think you should use "gauge".
(AFAICT from Wiktionary this is not a US/UK spelling thing.)

> +Voting is conducted in line with the following rules:
> +
> +-   Project leadership team members vote for (**+1**) or against (**-1**) a 
> +resolution. There is no differentiation between **+1**/ **+2** and 
> +**-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as 
> a 
> +vote against the resolution. The number of votes for and against a 
> resolution 
> +is called **active vote**. **0** votes **are not counted** as an active vote.
> +-   A **quorum of more than 50% of active votes** is required for a 
> resolution 
> +to pass. In other words, if the leadership team has 7 members, at least 4 
> +active votes are required for a resolution to pass.
> +-   The resolution passes, if a 2/3 majority of active votes is in favour of 
> +it. 

Quorums like this should count only positive votes.  Otherwise someone
who opposes a proposal has to guess whether it is more likely to fail
quorum, or to fail the 2/3 majority.  If it is likely to fail quorum,
they should refrain from voting.

For example with a team of 6, with two people having alread voted yes,
and the remaining three having expressly declined to vote because they
don't have an opinion, a leadership team member who votes "no" would
move the outcome from "quorum not met since only 2 out of 6 active
voters - fail" to "quorum met with 3 active voters, 2 votes in favour,
one against, 2/3 majority met - pass".

I suggest changing the quorum threshold to count only explicit
abstentions and votes in favour; either 1/3 or 50% would do.


> -### Conflict Resolution
> +Let me express this as an algorithm.
>  
> -
> -
> -ISSUES TO BE ADDRESSED LATER: 
> -- Generalise refereeing in terms of Project Leadership instead of 
> specific roles
> -- Also some examples for sPecific situations that have happened in the 
> past may be 
> -  useful
> -
> -
> +  treshhold=2/3;

 threshold

> +  active='number of active members'; (7 for the Hypervisor project; IanC 
> is inactive)

 ^
   at the time of writing, 
2016-09-20

> - Refereeing
> +One open question is what to do with 0-votes. We could introduce a rule 
> discounting 
> +0 votes (let's call it 0-rule). If someone votes 0, we assume they 
> really don't care
> +about the outcome and are considered inactive for the purpose of the 
> vote. 

With my proposal you can delete this because 0-votes do not affect
quorum.

> +The other question is whether to treat -2-votes different than -1-votes. 
> We could
> +say there should not be more than 20% -2-votes. That would mean that

No.  Formal decisonmaking of this sort should not count some votes
double.

> +The entire last resource section goes, because it is essentially not 
> needed any more, 
   
   resort

> + Committer, Security Team Member and other Project Leadership Elections
...
>  -   Nomination: Community members should nominate candidates by posting a 
>  proposal to *appointments at xenproject dot org* explaining the candidate's 
> @@ -299,74 +606,123 @@ review all proposals, check whether the nominee would 
> be willing to accept the
>  nomination and publish suitable nominations on the project's public mailing 
>  list for wider community input.
>  -   Election: A committer will be elected using the decision making process 
> -outlined earlier. Voting will be done by committers for that project 
> privately 
> -using a voting form that is created by the community manager. Should there 
> be a 
> -negative vote the project lead and community manager will try and resolve 
> the 
> -situation and reach consensus. Results will be published on the public 
> mailing 
> -list.
> +outlined earlier. In other words, the decision is delegated to the [project 
> +leadership team](#leadership).

This misses out appointments to the security team.  I suggest that
they should usually be made by the team itself according to lazy
consensus.

> +  
> -
>
> +  **Proposal**  **Who reviews?**  **Who votes?**
> +  - - 
> -   
> +  Creating, graduating, Members of developer mailing  Leadership 
> teams of 
> + 

[Xen-devel] [xen-4.5-testing bisection] complete build-amd64

[osstest service owner]

branch xen-4.5-testing
xenbranch xen-4.5-testing
job build-amd64
testid xen-build

Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  22857ab3492c35aac27691ae7184dcc935c5fb2a
  Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101048/


  commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
  Author: Jan Beulich 
  Date:   Mon Sep 19 17:50:59 2016 +0200
  
  update Xen version to 4.5.4


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.5-testing/build-amd64.xen-build 
--summary-out=tmp/101048.bisection-summary --basis-template=100909 
--blessings=real,real-bisect xen-4.5-testing build-amd64 xen-build
Searching for failure / basis pass:
 101024 fail [host=fiano1] / 100909 [host=godello0] 100897 [host=godello0] 
100828 [host=huxelrebe0] 100814 ok.
Failure / basis pass flights: 101024 / 100814
(tree with no url: ovmf)
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
Basis pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
433ebca120e8750eb8085745ccac703e47358e6f
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#835c204f1196ab8f5213a9dc5299ed76e748cdca-835c204f1196ab8f5213a9dc5299ed76e748cdca
 
git://xenbits.xen.org/xen.git#433ebca120e8750eb8085745ccac703e47358e6f-22857ab3492c35aac27691ae7184dcc935c5fb2a
Loaded 1001 nodes in revision graph
Searching for test results:
 100849 [host=godello0]
 100814 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
433ebca120e8750eb8085745ccac703e47358e6f
 100828 [host=huxelrebe0]
 100897 [host=godello0]
 100930 [host=huxelrebe0]
 100934 [host=huxelrebe1]
 100909 [host=godello0]
 101015 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101046 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
 101048 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101023 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
433ebca120e8750eb8085745ccac703e47358e6f
 101030 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101033 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
95559492c958e45fa7c01b1b3e0fb704e5b8b9eb
 101034 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
9edce7c42e6c2e8dd19788cab688cb46f779a9ec
 101035 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
 101037 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101039 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
 101024 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
 101044 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca 
22857ab3492c35aac27691ae7184dcc935c5fb2a
Searching for interesting versions
 Result found: flight 100814 (pass), for basis pass
 Result found: flight 101015 (fail), for basis failure
 Repro found: flight 101023 (pass), for basis pass
 Repro found: flight 101024 (fail), for basis failure
 0 revisions at 835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
No revisions left to test, checking graph state.
 Result found: flight 101035 (pass), for last pass
 Result found: flight 101037 (fail), for first failure
 Repro found: flight 101039 (pass), for last pass
 Repro found: flight 101044 (fail), for first failure
 Repro found: flight 101046 (pass), for last pass
 Repro found: flight 101048 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  22857ab3492c35aac27691ae7184dcc935c5fb2a
  Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101048/


  commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
  Author: Jan Beulich 
  Date:   Mon Sep 19 17:50:59 2016 +0200
  
  update Xen version to 4.5.4

Revision graph left in 
/home/logs/results/bisect/xen-4.5-testing/build-amd64.xen-build.{dot,ps,png,html,svg}.

101048: tolerable ALL FAIL

flight 101048 xen-4.5-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/101048/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests 

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

[Joao Martins]

On 09/20/2016 02:55 PM, Jan Beulich wrote:
 On 20.09.16 at 12:15,  wrote:
>> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>> On 19.09.16 at 19:54,  wrote:
 On 09/19/2016 05:25 PM, Jan Beulich wrote:
 On 19.09.16 at 18:11,  wrote:
>> On 09/19/2016 11:13 AM, Jan Beulich wrote:
>> On 14.09.16 at 19:37,  wrote:
 Since b64438c7c ("x86/time: use correct (local) time stamp in
 constant-TSC calibration fast path") updates to cpu time use local
 stamps, which means platform timer is only used to seed the initial
 cpu time.  With clocksource=tsc there is no need to be in sync with
 another clocksource, so we reseed the local/master stamps to be values
 of TSC and update the platform time stamps accordingly. Time
 calibration is set to 1sec after we switch to TSC, thus these stamps
 are reseeded to also ensure monotonic returning values right after the
 point we switch to TSC. This is also to avoid the possibility of
 having inconsistent readings in this short period (i.e. until
 calibration fires).
>>>
>>> And within this one second, which may cover some of Dom0's
>>> booting up, it is okay to have inconsistencies?
>> It's not okay which is why I am removing this possibility when switching 
>> to TSC.
>> The inconsistencies in those readings (if I wasn't adjusting) would be 
>> because
>> we would be using (in that 1-sec) those cpu time tuples calculated by the
>> previous calibration or platform time initialization (while still was 
>> HPET,
>> ACPI, etc as clocksource). Would you prefer me removing the "avoid" and 
>> instead
>> change it to "remove the possibility" in this last sentence?
>
> Let's not do the 2nd step before the 1st, which is the question of
> what happens prior to and what actually changes at this first
> calibration (after 1 sec).
 The first calibration won't change much - this 1-sec was meant when having
 nop_rendezvous which is the first time platform timer would be used to set 
 local
 cpu_time (will adjust the mention above as it's misleading for the reader 
 as it
 doesn't refer to this patch).
>>>
>>> So what makes it that it actually _is_ nop_rendezvous after that one
>>> second? (And yes, part of this may indeed be just bad placement of
>>> the description, as iirc nop_rendezvous gets introduced only in a later
>>> patch.)
>> Because with nop_rendezvous we will be using the platform timer to get a
>> monotonic time tuple and *set* cpu_time as opposed to just adding up plain 
>> TSC
>> delta as it is the case prior to b64438c7c. Thus the reseeding of the cpu 
>> times
>> solves both ends of the problem, with nop_rendezvous until it is first
>> calibration fixes it, and without nop_rendezvous to remove the latch 
>> adjustment
>> from initial platform timer.
> 
> So am I getting you right (together with the second part of your reply
> further down) that you escape answering the question raised by saying
> that it doesn't really matter which rendezvous function gets used, when
> TSC is the clock source?
Correct and in my defense I wasn't escaping the question, as despite
unfortunate mis-mention in the patch (or bad English) I think the above
explains it. During that time window, we now just need to ensure that we will
get monotonic results solely based on the individual CPU time (i.e. calls to
get_s_time or anything that uses cpu_time). Unless the calibration function is
doing something wrong/fishy, I don't see a reason for this to go wrong.

> I.e. the introduction of nop_rendezvous is
> really just to avoid unnecessary overhead?
Yes, but note that it's only the case since recent commit b64438c7c where
cpu_time stime is now incremented with TSC based deltas with a matching TSC
stamp. Before it wasn't the case. The main difference with nop_rendezvous (other
than the significant overhead) versus std_rendezvous is that we use a single
global tuple propagated to all cpus, whereas with std_rendezvous each tuple is
different and will vary according to when it rendezvous with cpu 0.

> In which case it should
> probably be a separate patch, saying so in its description.
OK, will move that out of Patch 4 into its own while keeping the same logic.

Joao

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

[Xen-devel] [libvirt test] 101029: regressions - trouble: blocked/broken/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep  fail REGR. vs. 100999

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

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

Last test of basis   100999  2016-09-18 04:20:39 Z2 days
Testing same since   101029  2016-09-20 04:23:33 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  Daniel P. Berrange 
  Eric Blake 
  Laine Stump 
  Martin Kletzander 
  Michal Privoznik 

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



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

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

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

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


Not pushing.


commit 4e2d642afb454738b2e06caffeb86d20b6f33a15
Author: Laine Stump 
Date:   Mon Sep 19 13:44:21 2016 -0400

tests: fix use of fixedcontent variable

Commit 8563560026d192c2cf047b550ffd468692245ed6 switched from
hardcoded use of strcontent to hardcoded use of fixedcontent
(fixedcontent is *sometimes* a copy of strcontent with a \n
appended). This was a problem because sometimes fixedcontent is *not*
a copy of strcontent, but is instead NULL, leading to the regenerated
test case output being a 0 length file.

This patch creates a new const char *cmpcontent initialized 

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Tue, Sep 20, 2016 at 9:39 AM, Jan Beulich  wrote:
 On 20.09.16 at 17:14,  wrote:
>> On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich  wrote:
>> On 20.09.16 at 16:56,  wrote:
 On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
 On 19.09.16 at 20:27,  wrote:
>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
>> On 15.09.16 at 18:51,  wrote:
 @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct 
 hvm_emulate_ctxt
>> *hvmemul_ctxt,
  pfec |= PFEC_user_mode;

  hvmemul_ctxt->insn_buf_eip = regs->eip;
 -if ( !vio->mmio_insn_bytes )
 +
 +if ( unlikely(hvmemul_ctxt->set_context_insn) && 
 curr->arch.vm_event )
 +{
 +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
 + sizeof(curr->arch.vm_event->emul.insn));
>>>
>>> This should quite clearly be !=, and I think it builds only because you
>>> use the wrong operand in the first sizeof().
>>>
 +hvmemul_ctxt->insn_buf_bytes = 
 sizeof(curr->arch.vm_event->emul.insn);
 +memcpy(hvmemul_ctxt->insn_buf, 
 >arch.vm_event->emul.insn,
 +   hvmemul_ctxt->insn_buf_bytes);
>>>
>>> This memcpy()s between dissimilar types. Please omit the & and
>>> properly add .data on the second argument (and this .data
>>> addition should then also be mirrored in the BUILD_BUG_ON()).
>>>
 +}
 +else if ( !vio->mmio_insn_bytes )
>>>
>>> And then - I'm sorry for not having thought of this before - I think
>>> this would better not live here, or have an effect more explicitly
>>> only when coming here through hvm_emulate_one_vm_event().
>>> Since the former seems impractical, I think giving _hvm_emulate_one()
>>> one or two extra parameters would be the most straightforward
>>> approach.
>>
>> So this is the spot where the mmio insn buffer is getting copied as
>> well instead of fetching the instructions from the guest memory. So
>> having the vm_event buffer getting copied here too makes the most
>> sense. Having the vm_event insn buffer getting copied in somewhere
>> else, while the mmio insn buffer getting copied here, IMHO just
>> fragments the flow even more making it harder to see what is actually
>> happening.
>
> And I didn't unconditionally ask to move the copying elsewhere.
> The alternative - passing the override in as function argument(s),
> which would then be NULL/zero for all cases except the VM event
> one, would be as suitable. It is in particular ...
>
>> How about adjusting the if-else here to be:
>>
>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
>> ...
>> else if ( vio->mmio_insn_bytes )
>> ...
>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && 
>> curr->arch.vm_event )
>
> ... this curr->arch.vm_event reference which I'd like to see gone
> from this specific code path. The ordering in your original patch,
> otoh, would then be fine (check for the override first with unlikely(),
> else do what is being done today). Such a code structure would
> then also ease a possible second way of overriding the insn by
> some other party, without having to touch the code here again.

 So that check is one that Razvan asked to be added. I think it is
 necessary too as there seems to be a race-condition if vm_event gets
 shutdown after the response flag is set but before this emulation path
 takes place. Effectively set_context_insn may be set but the
 arch.vm_event already gotten freed. Razvan, is that correct?
>>>
>>> Well, in case you misunderstood: I didn't ask for the check to be
>>> _removed_, but for it to be _moved elsewhere_.
>>>
>>
>> So as Razvan pointed out, there is a check already in hvm_do_resume
>> for exactly the same effect, so then what you are asking for is
>> already done.
>
> Partly - I really meant all curr->arch.vm_event uses to go away from
> that path. The other part (passing in the override buffer instead of
> special casing vm-event handling here) still would need to be done.
>

I don't really follow what exactly you are looking for. You want the
buffer to be sent in as an input? We can do that but I mean the mmio
case doesn't do that either.. And what do you mean not "special casing
vm_event handling"? We need to handle it in an if-statement because by
default the buffer is fetched from memory. We don't want to do that,
just as the mmio case doesn't want that either. So I think if we want
to be consistent we do what the mmio case is doing, fetching the
buffer from 

[Xen-devel] [xen-4.6-testing test] 101026: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 101016 pass 
in 101026
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101016 pass 
in 101026
 test-armhf-armhf-xl  16 guest-start.2  fail pass in 101016
 test-armhf-armhf-xl-cubietruck 16 guest-start.2fail pass in 101016

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101016 like 
100957
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100907
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100957
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100957
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100957
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100957

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

version targeted for testing:
 xen  57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a
baseline version:
 xen  3cffa34537767dfdb6a0fa02c1a54fdfc7644b6d

Last test of basis   100957  2016-09-14 16:12:51 Z5 days
Testing same since   101016  2016-09-19 16:14:13 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Marek Marczykowski-Górecki 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Jan Beulich]

>>> On 20.09.16 at 17:14,  wrote:
> On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich  wrote:
> On 20.09.16 at 16:56,  wrote:
>>> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
>>> On 19.09.16 at 20:27,  wrote:
> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
> On 15.09.16 at 18:51,  wrote:
>>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct 
>>> hvm_emulate_ctxt
> *hvmemul_ctxt,
>>>  pfec |= PFEC_user_mode;
>>>
>>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>>> -if ( !vio->mmio_insn_bytes )
>>> +
>>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && 
>>> curr->arch.vm_event )
>>> +{
>>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>>> + sizeof(curr->arch.vm_event->emul.insn));
>>
>> This should quite clearly be !=, and I think it builds only because you
>> use the wrong operand in the first sizeof().
>>
>>> +hvmemul_ctxt->insn_buf_bytes = 
>>> sizeof(curr->arch.vm_event->emul.insn);
>>> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
>>> +   hvmemul_ctxt->insn_buf_bytes);
>>
>> This memcpy()s between dissimilar types. Please omit the & and
>> properly add .data on the second argument (and this .data
>> addition should then also be mirrored in the BUILD_BUG_ON()).
>>
>>> +}
>>> +else if ( !vio->mmio_insn_bytes )
>>
>> And then - I'm sorry for not having thought of this before - I think
>> this would better not live here, or have an effect more explicitly
>> only when coming here through hvm_emulate_one_vm_event().
>> Since the former seems impractical, I think giving _hvm_emulate_one()
>> one or two extra parameters would be the most straightforward
>> approach.
>
> So this is the spot where the mmio insn buffer is getting copied as
> well instead of fetching the instructions from the guest memory. So
> having the vm_event buffer getting copied here too makes the most
> sense. Having the vm_event insn buffer getting copied in somewhere
> else, while the mmio insn buffer getting copied here, IMHO just
> fragments the flow even more making it harder to see what is actually
> happening.

 And I didn't unconditionally ask to move the copying elsewhere.
 The alternative - passing the override in as function argument(s),
 which would then be NULL/zero for all cases except the VM event
 one, would be as suitable. It is in particular ...

> How about adjusting the if-else here to be:
>
> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
> ...
> else if ( vio->mmio_insn_bytes )
> ...
> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event 
> )

 ... this curr->arch.vm_event reference which I'd like to see gone
 from this specific code path. The ordering in your original patch,
 otoh, would then be fine (check for the override first with unlikely(),
 else do what is being done today). Such a code structure would
 then also ease a possible second way of overriding the insn by
 some other party, without having to touch the code here again.
>>>
>>> So that check is one that Razvan asked to be added. I think it is
>>> necessary too as there seems to be a race-condition if vm_event gets
>>> shutdown after the response flag is set but before this emulation path
>>> takes place. Effectively set_context_insn may be set but the
>>> arch.vm_event already gotten freed. Razvan, is that correct?
>>
>> Well, in case you misunderstood: I didn't ask for the check to be
>> _removed_, but for it to be _moved elsewhere_.
>>
> 
> So as Razvan pointed out, there is a check already in hvm_do_resume
> for exactly the same effect, so then what you are asking for is
> already done.

Partly - I really meant all curr->arch.vm_event uses to go away from
that path. The other part (passing in the override buffer instead of
special casing vm-event handling here) still would need to be done.

Jan

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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Jan Beulich]

>>> On 20.09.16 at 16:52,  wrote:
> On 9/19/2016 10:46 PM, Jan Beulich wrote:
 Well, without a clear understanding of why the issue occurs (for
 >> which I need to refer you back to the questionable stack dump)
 >> I'm hesitant to agree to this step, yet ...
>>> >
>>> > After some researches, I found do_invalid_op() on the stack dump is
>>> > caused by run_in_exception_handler(__ns16550_poll) in the ns16550_poll()
>>> > rather than fatal event. The timeout issue still exists when run
>>> > __ns16550_poll() directly in the ns16550_poll().
>> Well, I then still don't see why e.g. dump_domains() doesn't also need
>> it.
> 
> After testing, dump_domains() also has such issue after I create two VM
> with 128 vcpus.
> 
>> Earlier you did say:
>>
>>   Keyhandler may run in the timer handler and the following log shows
>>   calltrace. The timer subsystem run all expired timers' handler
>>   before programing next timer event. If keyhandler runs longer than
>>   timeout, there will be no chance to configure timer before triggering
>>   watchdog and hypervisor rebooting.
>>
>> The fact that using debug keys may adversely affect the rest of the
>> system is known. And the nesting of process_pending_softirqs()
>> inside do_softirq() should, from looking at them, work fine. So I
>> continue to have trouble seeing the specific reason for the problem
>> you say you observe.
> 
> The precondition of process_pending_softirq() working in the debug key
> handler is that timer interrupt arrives on time and nmi_timer_fn() can
> run to update nmi_timer_ticks before watchdog timeout.

Precondition?

> When a timer interrupt arrives, timer_softirq_action() will run all
> expired timer handlers before programing next timer interrupt via
> reprogram_timer(). If a timer handler runs too long E,G >5s(Time for
> watchdog timeout is default to be 5s.), this will cause no timer
> interrupt arriving within 5s and nmi_timer_fn() also won't be called.
> Does this make sense to you?

Partly. I continue to think that the sequence

some keyhandler
timer interrupt
keyhandler continues
keyhandler calls process_pending_softirq()

should, among other things, result in timer_softirq_action() to get
run. And I don't see the _timer_ handler running for to long here,
only a key handler. Are you perhaps instead suffering from the
nested instance of timer_softirq_action() not being able to acquire
its lock? That would be an entirely different issue than you had
described so far.

And irrespective of this it is of course quite clear that timers aren't
meant to run heavyweight work like key handlers, so the way
ns16550_poll() works right now is probably what we'll want to alter.
Which btw raises another question: Why are you in polling mode in
the first place? Do you have a UART without working interrupt?

Jan


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

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

[Julien Grall]

Hi,

On 20/09/2016 12:27, George Dunlap wrote:

On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan  wrote:

On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:

On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Dario Faggioli wrote:

I'd like to add a computing capability in xen/arm, like this:

struct compute_capatiliby
{
   char *core_name;
   uint32_t rank;
   uint32_t cpu_partnum;
};

struct compute_capatiliby cc=
{
  {"A72", 4, 0xd08},
  {"A57", 3, 0},
  {"A53", 2, 0xd03},
  {"A35", 1, ...},
}

Then when identify cpu, we decide which cpu is big and which cpu is little
according to the computing rank.

Any comments?


I think we definitely need to have Xen have some kind of idea the
order between processors, so that the user doesn't need to figure out
which class / pool is big and which pool is LITTLE.  Whether this sort
of enumeration is the best way to do that I'll let Julien and Stefano
give their opinion.


I don't think an hardcoded list of processor in Xen is the right 
solution. There are many existing processors and combinations for 
big.LITTLE so it will nearly be impossible to keep updated.


I would expect the firmware table (device tree, ACPI) to provide 
relevant data for each processor and differentiate big from LITTLE core.
Note that I haven't looked at it for now. A good place to start is 
looking at how Linux does.


Regards,


--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Mon, Sep 19, 2016 at 6:36 PM, Tian, Kevin  wrote:
>> From: Tamas K Lengyel
>> Sent: Tuesday, September 20, 2016 12:40 AM
>>
>> >> --- a/xen/arch/x86/hvm/hvm.c
>> >> +++ b/xen/arch/x86/hvm/hvm.c
>> >> @@ -489,13 +489,16 @@ void hvm_do_resume(struct vcpu *v)
>> >>
>> >>  if ( v->arch.vm_event->emulate_flags &
>> >>   VM_EVENT_FLAG_SET_EMUL_READ_DATA )
>> >> -kind = EMUL_KIND_SET_CONTEXT;
>> >> +kind = EMUL_KIND_SET_CONTEXT_DATA;
>> >>  else if ( v->arch.vm_event->emulate_flags &
>> >>VM_EVENT_FLAG_EMULATE_NOWRITE )
>> >>  kind = EMUL_KIND_NOWRITE;
>> >> +else if ( v->arch.vm_event->emulate_flags &
>> >> + VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
>> >> +kind = EMUL_KIND_SET_CONTEXT_INSN;
>> >
>> > The header talking about incompatibilities between these flags -
>> > wouldn't it be a good idea to actually -EINVAL such combinations?
>>
>> The header just points out that setting all these flags at the same
>> time won't have a "combined" effect - evident from the if-else
>> treatment above. There is really no point to do an error, the error
>> would never reach the user. Setting response flags through vm_event
>> doesn't have an error-path back.
>>
>
> Maybe you can have an explicit comment on priority of those flags,
> so consistent behavior can be expected moving forward. e.g. above
> code implies read_data>nowrite>insn_data. w/o a proper guidance
> here, future code changes by others may break that sequence...
>

Fair point, will do that.

Thanks,
Tamas

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

Re: [Xen-devel] New Outreachy Applicant

[George Dunlap]

On Wed, Sep 14, 2016 at 7:35 AM, Ronald Rojas  wrote:
> Hi, I'm Ronald Rojas an undergraduate junior studying
> computer science at New York Unversity. I would like
> to apply fo the Xen projects Outreachy Program. After
> looking through the available projects I think I would
> be a good fit for creating the golang bindings for
> libxl. I'm proficient in C , familar with Golang, and
> very comfortable with linux. Would I be able to get a
> bit-sized task for the application process?

Ronald,

Thanks for your interest in the Xen Project!  Sorry for the delay in
responding -- somehow your mail either never made it to my personal
inbox or I accidentally deleted it instead of filing it properly.  I
saw your question on IRC and now found your mail here on xen-devel.

First, I want to emphasize that Outreachy internships should be
considered a full-time job.  As part of the application process you
will be asked to confirm that you will not be taking any classes, nor
have any other significant commitments (such as another job) during
the period of the internship.

Now on to the bite-sized task.  We've actually found that one of the
difficult parts of getting going with our project is making sure that
you understand how to get your whole system and environment set up.
And another thing we want to see is to what degree you can balance
figuring things out, finding the answers on the web, and asking for
help when you need it.

So with that in mind, we've started experimenting with tasks which
don't contribute very much to the project directly, but provide a
really solid base of knowledge to do further contributions.

So here's my challenge for you.

---
OUTCOME

Attached is the very beginnings of a set of golang bindings that I
wrote for a project of my own.  They contain an implementation of
Context.Open() and Context.ListCpupool().

Write a simple go program that will list the current cpu pools,
similar to the output of "xl cpupool-list".  No need to handle extra
arguments or modify libxl.go (beyond what may be needed to compile it).

Please post a copy of your .go program, along with the results of
output *when more than one VM is running*.

STEPS

1. Set up a system running Linux

If you don't have one, Ubuntu, Fedora, or Debian should all be fine.

2. Download, build, and install the latest development
version of Xen.  The following page should be useful:

https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source

I would recommend using "make debball" or "make rpmball" over the
"make install".

3. You'll need to build an image for at least one guest VM.

There are tons of options here, but one really simple thing would be
to follow this HOWTO from a previous OPW intern:

https://umasharma17.wordpress.com/2015/02/13/creating-guests-using-xl-in-xen/

4. Write your go program

The go program will need to Open() the context, then call DomainInfo()
on the target domain ID, and output the required info based on "xl
list".

libxl.go uses cgo to compile a library against C.  If you have the
libraries set up properly, the current version should just work.

--

That's it!  Remember that the goal of this is to see how well you
balance figuring things out on your own vs asking questions.  So try
to figure things out on your own, but when you run into a bit of
difficultly, don't hesitate to ask questions or clarification --
particularly at the beginning.

You can ask questions either here on xen-devel or on the #xendevel or
#xen-opw channels on freenode IRC.

Good luck,
 -George
/*
 * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; version 2 of the
 * License only.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 * 02110-1301, USA.
 */
package main

/*
#cgo LDFLAGS: -lyajl -lxenlight
#include 
#include 
*/
import "C"

import (
	"unsafe"
	"fmt"
	"time"
)

type Context struct {
	ctx *C.libxl_ctx
}

var Ctx Context

func (Ctx *Context) IsOpen() bool {
	return Ctx.ctx != nil
}

func (Ctx *Context) Open() (err error) {
	if Ctx.ctx != nil {
		return
	}
	
	ret := C.libxl_ctx_alloc(unsafe.Pointer(), C.LIBXL_VERSION, 0, nil)

	if ret != 0 {
		err = fmt.Errorf("Allocating libxl context: %d", ret)
	}
	return
}

func (Ctx *Context) Close() (err error) {
	ret := C.libxl_ctx_free(unsafe.Pointer(Ctx.ctx))
	Ctx.ctx = nil

	if ret != 0 {
		err = fmt.Errorf("Freeing libxl context: %d", ret)
	}
	return
}

type Domid uint32

type 

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich  wrote:
 On 20.09.16 at 16:56,  wrote:
>> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
>> On 19.09.16 at 20:27,  wrote:
 On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
 On 15.09.16 at 18:51,  wrote:
>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct 
>> hvm_emulate_ctxt
 *hvmemul_ctxt,
>>  pfec |= PFEC_user_mode;
>>
>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>> -if ( !vio->mmio_insn_bytes )
>> +
>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && 
>> curr->arch.vm_event )
>> +{
>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>> + sizeof(curr->arch.vm_event->emul.insn));
>
> This should quite clearly be !=, and I think it builds only because you
> use the wrong operand in the first sizeof().
>
>> +hvmemul_ctxt->insn_buf_bytes = 
>> sizeof(curr->arch.vm_event->emul.insn);
>> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
>> +   hvmemul_ctxt->insn_buf_bytes);
>
> This memcpy()s between dissimilar types. Please omit the & and
> properly add .data on the second argument (and this .data
> addition should then also be mirrored in the BUILD_BUG_ON()).
>
>> +}
>> +else if ( !vio->mmio_insn_bytes )
>
> And then - I'm sorry for not having thought of this before - I think
> this would better not live here, or have an effect more explicitly
> only when coming here through hvm_emulate_one_vm_event().
> Since the former seems impractical, I think giving _hvm_emulate_one()
> one or two extra parameters would be the most straightforward
> approach.

 So this is the spot where the mmio insn buffer is getting copied as
 well instead of fetching the instructions from the guest memory. So
 having the vm_event buffer getting copied here too makes the most
 sense. Having the vm_event insn buffer getting copied in somewhere
 else, while the mmio insn buffer getting copied here, IMHO just
 fragments the flow even more making it harder to see what is actually
 happening.
>>>
>>> And I didn't unconditionally ask to move the copying elsewhere.
>>> The alternative - passing the override in as function argument(s),
>>> which would then be NULL/zero for all cases except the VM event
>>> one, would be as suitable. It is in particular ...
>>>
 How about adjusting the if-else here to be:

 if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
 ...
 else if ( vio->mmio_insn_bytes )
 ...
 else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>>
>>> ... this curr->arch.vm_event reference which I'd like to see gone
>>> from this specific code path. The ordering in your original patch,
>>> otoh, would then be fine (check for the override first with unlikely(),
>>> else do what is being done today). Such a code structure would
>>> then also ease a possible second way of overriding the insn by
>>> some other party, without having to touch the code here again.
>>
>> So that check is one that Razvan asked to be added. I think it is
>> necessary too as there seems to be a race-condition if vm_event gets
>> shutdown after the response flag is set but before this emulation path
>> takes place. Effectively set_context_insn may be set but the
>> arch.vm_event already gotten freed. Razvan, is that correct?
>
> Well, in case you misunderstood: I didn't ask for the check to be
> _removed_, but for it to be _moved elsewhere_.
>

So as Razvan pointed out, there is a check already in hvm_do_resume
for exactly the same effect, so then what you are asking for is
already done.

Tamas

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Jan Beulich]

>>> On 20.09.16 at 16:56,  wrote:
> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
> On 19.09.16 at 20:27,  wrote:
>>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
>>> On 15.09.16 at 18:51,  wrote:
> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>>> *hvmemul_ctxt,
>  pfec |= PFEC_user_mode;
>
>  hvmemul_ctxt->insn_buf_eip = regs->eip;
> -if ( !vio->mmio_insn_bytes )
> +
> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event 
> )
> +{
> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
> + sizeof(curr->arch.vm_event->emul.insn));

 This should quite clearly be !=, and I think it builds only because you
 use the wrong operand in the first sizeof().

> +hvmemul_ctxt->insn_buf_bytes = 
> sizeof(curr->arch.vm_event->emul.insn);
> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
> +   hvmemul_ctxt->insn_buf_bytes);

 This memcpy()s between dissimilar types. Please omit the & and
 properly add .data on the second argument (and this .data
 addition should then also be mirrored in the BUILD_BUG_ON()).

> +}
> +else if ( !vio->mmio_insn_bytes )

 And then - I'm sorry for not having thought of this before - I think
 this would better not live here, or have an effect more explicitly
 only when coming here through hvm_emulate_one_vm_event().
 Since the former seems impractical, I think giving _hvm_emulate_one()
 one or two extra parameters would be the most straightforward
 approach.
>>>
>>> So this is the spot where the mmio insn buffer is getting copied as
>>> well instead of fetching the instructions from the guest memory. So
>>> having the vm_event buffer getting copied here too makes the most
>>> sense. Having the vm_event insn buffer getting copied in somewhere
>>> else, while the mmio insn buffer getting copied here, IMHO just
>>> fragments the flow even more making it harder to see what is actually
>>> happening.
>>
>> And I didn't unconditionally ask to move the copying elsewhere.
>> The alternative - passing the override in as function argument(s),
>> which would then be NULL/zero for all cases except the VM event
>> one, would be as suitable. It is in particular ...
>>
>>> How about adjusting the if-else here to be:
>>>
>>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
>>> ...
>>> else if ( vio->mmio_insn_bytes )
>>> ...
>>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>
>> ... this curr->arch.vm_event reference which I'd like to see gone
>> from this specific code path. The ordering in your original patch,
>> otoh, would then be fine (check for the override first with unlikely(),
>> else do what is being done today). Such a code structure would
>> then also ease a possible second way of overriding the insn by
>> some other party, without having to touch the code here again.
> 
> So that check is one that Razvan asked to be added. I think it is
> necessary too as there seems to be a race-condition if vm_event gets
> shutdown after the response flag is set but before this emulation path
> takes place. Effectively set_context_insn may be set but the
> arch.vm_event already gotten freed. Razvan, is that correct?

Well, in case you misunderstood: I didn't ask for the check to be
_removed_, but for it to be _moved elsewhere_.

Jan


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

Re: [Xen-devel] [PATCH 13/24] libxc: improve error handling of xc Credit1 and Credit2 helpers

[Wei Liu]

On Wed, Aug 17, 2016 at 07:19:04PM +0200, Dario Faggioli wrote:
> In fact, libxc wrappers should, on error, set errno and
> return -1.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Razvan Cojocaru]

On 09/20/2016 05:56 PM, Tamas K Lengyel wrote:
> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
> On 19.09.16 at 20:27,  wrote:
>>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
>>> On 15.09.16 at 18:51,  wrote:
> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>>> *hvmemul_ctxt,
>  pfec |= PFEC_user_mode;
>
>  hvmemul_ctxt->insn_buf_eip = regs->eip;
> -if ( !vio->mmio_insn_bytes )
> +
> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event 
> )
> +{
> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
> + sizeof(curr->arch.vm_event->emul.insn));

 This should quite clearly be !=, and I think it builds only because you
 use the wrong operand in the first sizeof().

> +hvmemul_ctxt->insn_buf_bytes = 
> sizeof(curr->arch.vm_event->emul.insn);
> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
> +   hvmemul_ctxt->insn_buf_bytes);

 This memcpy()s between dissimilar types. Please omit the & and
 properly add .data on the second argument (and this .data
 addition should then also be mirrored in the BUILD_BUG_ON()).

> +}
> +else if ( !vio->mmio_insn_bytes )

 And then - I'm sorry for not having thought of this before - I think
 this would better not live here, or have an effect more explicitly
 only when coming here through hvm_emulate_one_vm_event().
 Since the former seems impractical, I think giving _hvm_emulate_one()
 one or two extra parameters would be the most straightforward
 approach.
>>>
>>> So this is the spot where the mmio insn buffer is getting copied as
>>> well instead of fetching the instructions from the guest memory. So
>>> having the vm_event buffer getting copied here too makes the most
>>> sense. Having the vm_event insn buffer getting copied in somewhere
>>> else, while the mmio insn buffer getting copied here, IMHO just
>>> fragments the flow even more making it harder to see what is actually
>>> happening.
>>
>> And I didn't unconditionally ask to move the copying elsewhere.
>> The alternative - passing the override in as function argument(s),
>> which would then be NULL/zero for all cases except the VM event
>> one, would be as suitable. It is in particular ...
>>
>>> How about adjusting the if-else here to be:
>>>
>>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
>>> ...
>>> else if ( vio->mmio_insn_bytes )
>>> ...
>>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>
>> ... this curr->arch.vm_event reference which I'd like to see gone
>> from this specific code path. The ordering in your original patch,
>> otoh, would then be fine (check for the override first with unlikely(),
>> else do what is being done today). Such a code structure would
>> then also ease a possible second way of overriding the insn by
>> some other party, without having to touch the code here again.
>>
> 
> So that check is one that Razvan asked to be added. I think it is
> necessary too as there seems to be a race-condition if vm_event gets
> shutdown after the response flag is set but before this emulation path
> takes place. Effectively set_context_insn may be set but the
> arch.vm_event already gotten freed. Razvan, is that correct?

Yes, that's the general idea, but there's also already a check in
hvm_do_resume() right before calling hvm_mem_access_emulate_one(), so as
long as that's the only code path leading here it should be alright to
remove the check. The check adds extra safety but it's not strictly
necessary here, so if Jan prefers it taken out it should, theoretically,
be fine for now.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v4 0/4] libxl: add HVM USB passthrough capability

[Wei Liu]

On Tue, Sep 20, 2016 at 04:18:06PM +0200, Juergen Gross wrote:
> Add the capability to pass USB devices to HVM domains by using the
> emulation of USB controllers of qemu.
> 
> The user interface via xl is the same as for pvusb passthrough, only
> the type of the usbctrl is different: instead of "qusb" (qemu-based
> pvusb backend) or "vusb" (kernel-based pvusb backend) the type
> "devicemodel" is used.
> 
> Especially the communication with qemu via qmp commands is based on
> the patches of George Dunlap sent in 2014:
> 
> https://lists.xen.org/archives/html/xen-devel/2014-06/msg00085.html
> 
> Changes in V4:
> - patch 2: corrected libxl__device_destroy() to not use be_path being NULL
> 
> Changes in V3:
> - patch 3: rename pvusb_get_port_path() to vusb_get_port_path()
>   as requested by George Dunlap
> - patch 4: wording adjusted as requested by Ian Jackson
> 
> Changes in V2:
> - patches 1-3 removed as already pushed
> - split out (new) patch 1 from patch 3 (was 5) as requested by Wei Liu
> - addressed code style issues in patch 3 (was 5) as requested by Wei Liu
> - added some assert()s n patch 3 (was 5) as requested by Wei Liu
> 
> Juergen Gross (4):
>   libxl: add function to remove usb controller xenstore entries
>   libxl: add basic support for devices without backend
>   libxl: add HVM usb passthrough support
>   docs: add HVM USB passthrough documentation
> 
>  docs/man/xl.cfg.pod.5.in |  12 +-
>  tools/libxl/libxl_device.c   |  73 --
>  tools/libxl/libxl_types_internal.idl |   1 +
>  tools/libxl/libxl_usb.c  | 435 
> +++
>  tools/libxl/libxl_xshelp.c   |   6 +-
>  tools/libxl/xl_cmdimpl.c |   4 +-
>  6 files changed, 409 insertions(+), 122 deletions(-)
> 

Series pushed.

> -- 
> 2.6.6
> 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
baseline version:
 ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42

Last test of basis67720  2016-09-15 17:19:47 Z4 days
Testing same since67733  2016-09-20 11:46:17 Z0 days1 attempts


People who touched revisions under test:
  Hegde Nagaraj P 
  Jiaxin Wu 

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 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
Author: Jiaxin Wu 
Date:   Wed Sep 14 14:43:45 2016 +0800

NetworkPkg: Correct the DNS token return status by RCODE

When HostNameToIp() and GeneralLookUp() are called with a invalid
host name, RCODE (4 bit field is set as part of responses) error
will returned in packet to identify the domain name referenced in
the query does not exist. So, EFI_NOT_FOUND should be returned
directly.

Current implementation only check the RCODE in successful condition.
Need update the code for more error check according to RFC 1035 4.1.1
section.

Cc: Hegde Nagaraj P 
Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
Tested-by: Hegde Nagaraj P 
Reviewed-by: Sriram Subramanian 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
 On 19.09.16 at 20:27,  wrote:
>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
>> On 15.09.16 at 18:51,  wrote:
 @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>> *hvmemul_ctxt,
  pfec |= PFEC_user_mode;

  hvmemul_ctxt->insn_buf_eip = regs->eip;
 -if ( !vio->mmio_insn_bytes )
 +
 +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
 +{
 +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
 + sizeof(curr->arch.vm_event->emul.insn));
>>>
>>> This should quite clearly be !=, and I think it builds only because you
>>> use the wrong operand in the first sizeof().
>>>
 +hvmemul_ctxt->insn_buf_bytes = 
 sizeof(curr->arch.vm_event->emul.insn);
 +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
 +   hvmemul_ctxt->insn_buf_bytes);
>>>
>>> This memcpy()s between dissimilar types. Please omit the & and
>>> properly add .data on the second argument (and this .data
>>> addition should then also be mirrored in the BUILD_BUG_ON()).
>>>
 +}
 +else if ( !vio->mmio_insn_bytes )
>>>
>>> And then - I'm sorry for not having thought of this before - I think
>>> this would better not live here, or have an effect more explicitly
>>> only when coming here through hvm_emulate_one_vm_event().
>>> Since the former seems impractical, I think giving _hvm_emulate_one()
>>> one or two extra parameters would be the most straightforward
>>> approach.
>>
>> So this is the spot where the mmio insn buffer is getting copied as
>> well instead of fetching the instructions from the guest memory. So
>> having the vm_event buffer getting copied here too makes the most
>> sense. Having the vm_event insn buffer getting copied in somewhere
>> else, while the mmio insn buffer getting copied here, IMHO just
>> fragments the flow even more making it harder to see what is actually
>> happening.
>
> And I didn't unconditionally ask to move the copying elsewhere.
> The alternative - passing the override in as function argument(s),
> which would then be NULL/zero for all cases except the VM event
> one, would be as suitable. It is in particular ...
>
>> How about adjusting the if-else here to be:
>>
>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
>> ...
>> else if ( vio->mmio_insn_bytes )
>> ...
>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>
> ... this curr->arch.vm_event reference which I'd like to see gone
> from this specific code path. The ordering in your original patch,
> otoh, would then be fine (check for the override first with unlikely(),
> else do what is being done today). Such a code structure would
> then also ease a possible second way of overriding the insn by
> some other party, without having to touch the code here again.
>

So that check is one that Razvan asked to be added. I think it is
necessary too as there seems to be a race-condition if vm_event gets
shutdown after the response flag is set but before this emulation path
takes place. Effectively set_context_insn may be set but the
arch.vm_event already gotten freed. Razvan, is that correct?

Tamas

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

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/20/2016 10:19 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v4 02/21] acpi: Prevent GPL-only code 
> from seeping into non-GPL binaries"):
>> But yes, I can split dsdt.asl as well. Should we keep _S5 definition as
>> GPL-only?
> I think once we're going down this route there is no benefit in trying
> to argue for individual bits of code-that-was-once-Lenovo's that there
> is no copyright interest.
>
> So I would split those lines out as well.  That will mean multiple
> includes.
>
> Does iasl have a suitable conditional include syntax or are you going
> to use `cat' or something in the Makefile ?


iasl has -I option but I don't see a conditional. (And I have very
vague understanding of ASL syntax in case there is something that can be
done in the language itself).

I ran a quick test with 'cat' and it seems to work OK. Besides, we are
already using 'cat' implicitly: we append mk_dsdt output to existing
*asl file.


-boris



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Wei Liu]

On Tue, Sep 20, 2016 at 10:31:04AM +0800, Dongli Zhang wrote:
> This patch implemented parts of TODO left in commit id
> a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush
> filtering in alloc_heap_pages()). It moved TLB-flush filtering out into
> populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow
> to create a guest with memory size of more than 100GB on host with 100+
> cpus.
> 

Do you have some actual numbers on how much faster after applying this
patch?

This is mostly for writing release note etc, so it is fine if you don't
have numbers at hand.

Wei.

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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Lan, Tianyu]

On 9/19/2016 10:46 PM, Jan Beulich wrote:

Well, without a clear understanding of why the issue occurs (for
>> which I need to refer you back to the questionable stack dump)
>> I'm hesitant to agree to this step, yet ...

>
> After some researches, I found do_invalid_op() on the stack dump is
> caused by run_in_exception_handler(__ns16550_poll) in the ns16550_poll()
> rather than fatal event. The timeout issue still exists when run
> __ns16550_poll() directly in the ns16550_poll().

Well, I then still don't see why e.g. dump_domains() doesn't also need
it.


After testing, dump_domains() also has such issue after I create two VM
with 128 vcpus.


Earlier you did say:

  Keyhandler may run in the timer handler and the following log shows
  calltrace. The timer subsystem run all expired timers' handler
  before programing next timer event. If keyhandler runs longer than
  timeout, there will be no chance to configure timer before triggering
  watchdog and hypervisor rebooting.

The fact that using debug keys may adversely affect the rest of the
system is known. And the nesting of process_pending_softirqs()
inside do_softirq() should, from looking at them, work fine. So I
continue to have trouble seeing the specific reason for the problem
you say you observe.


The precondition of process_pending_softirq() working in the debug key
handler is that timer interrupt arrives on time and nmi_timer_fn() can
run to update nmi_timer_ticks before watchdog timeout.

When a timer interrupt arrives, timer_softirq_action() will run all
expired timer handlers before programing next timer interrupt via
reprogram_timer(). If a timer handler runs too long E,G >5s(Time for
watchdog timeout is default to be 5s.), this will cause no timer
interrupt arriving within 5s and nmi_timer_fn() also won't be called.
Does this make sense to you?



And as a separate note - dump_registers() is quite an exception
among the key handlers, and that's for a good reason (as the
comment there says). So I continue to be hesitant to see this
spread to other key handlers.

Jan



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

Re: [Xen-devel] [PATCH v4 3/4] libxl: add HVM usb passthrough support

[George Dunlap]

On 20/09/16 15:18, Juergen Gross wrote:
> Add HVM usb passthrough support to libxl by using qemu's capability
> to emulate standard USB controllers.
> 
> A USB controller is added via qmp command to the emulated hardware
> when a usbctrl device of type DEVICEMODEL is requested. Depending on
> the requested speed the appropriate hardware type is selected. A host
> USB device can then be added to the emulated USB controller via qmp
> command.
> 
> Removing of the devices is done via qmp commands, too.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Wei Liu 

Acked-by: George Dunlap 



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

Re: [Xen-devel] [PATCH v4 1/4] libxl: add function to remove usb controller xenstore entries

[Wei Liu]

On Tue, Sep 20, 2016 at 04:18:07PM +0200, Juergen Gross wrote:
> In case of failure when trying to add a new USB controller to a domain
> libxl might leak xenstore entries. Add a function to remove them and
> call this function in case of failure.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 12/24] xen: libxc: allow to set the ratelimit value online

[Wei Liu]

On Tue, Sep 20, 2016 at 03:43:57PM +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > The main purpose of the patch is to provide the xen-libxc
> > plumbing necessary to be able to change the value of the
> > ratelimit_us parameter online, for Credit2 (like it is
> > already for Credit1).
> > 
> > While there:
> >  - mention in the Xen logs when rate limiting was enables
> >and is being disabled (and vice-versa);
> >  - fix csched2_sys_cntl() which was always returning
> >-EINVAL in the XEN_SYSCTL_SCHEDOP_putinfo case.
> 
> How weird!
> 
> > 
> > And also:
> >  - fix style of an if in csched_sys_cntl();
> >  - fix the style of the switch in csched2_sys_cntl();
> > 
> > Signed-off-by: Dario Faggioli 
> 
> Reviewed-by: George Dunlap 
> 
> Wei / Ian, I think this is relatively independent of other changes -- if
> you give me an Ack for the tools side I can check this in.
> 

Here you go:

Acked-by: Wei Liu 

>   -George

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

Re: [Xen-devel] [PATCH 12/24] xen: libxc: allow to set the ratelimit value online

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> The main purpose of the patch is to provide the xen-libxc
> plumbing necessary to be able to change the value of the
> ratelimit_us parameter online, for Credit2 (like it is
> already for Credit1).
> 
> While there:
>  - mention in the Xen logs when rate limiting was enables
>and is being disabled (and vice-versa);
>  - fix csched2_sys_cntl() which was always returning
>-EINVAL in the XEN_SYSCTL_SCHEDOP_putinfo case.

How weird!

> 
> And also:
>  - fix style of an if in csched_sys_cntl();
>  - fix the style of the switch in csched2_sys_cntl();
> 
> Signed-off-by: Dario Faggioli 

Reviewed-by: George Dunlap 

Wei / Ian, I think this is relatively independent of other changes -- if
you give me an Ack for the tools side I can check this in.

  -George

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

Re: [Xen-devel] [PATCH 11/24] tools: tracing: handle more scheduling related events.

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> There are some scheduling related trace records that
> are not being taken care of (and hence only dumped as
> raw records).
> 
> Some of them are being introduced in this series, while
> other were just neglected by previous patches.
> 
> Add support for them.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/xentrace/formats|8 
>  tools/xentrace/xenalyze.c |  101 
> +
>  2 files changed, 109 insertions(+)
> 
> diff --git a/tools/xentrace/formats b/tools/xentrace/formats
> index adff681..3488a06 100644
> --- a/tools/xentrace/formats
> +++ b/tools/xentrace/formats
> @@ -42,6 +42,10 @@
>  0x00022004  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:stolen_vcpu   [ 
> dom:vcpu = 0x%(2)04x%(3)04x, from = %(1)d ]
>  0x00022005  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:picked_cpu[ 
> dom:vcpu = 0x%(1)04x%(2)04x, cpu = %(3)d ]
>  0x00022006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:tickle[ cpu = 
> %(1)d ]
> +0x00022007  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:boost [ 
> dom:vcpu = 0x%(1)04x%(2)04x ]
> +0x00022008  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:unboost   [ 
> dom:vcpu = 0x%(1)04x%(2)04x ]
> +0x00022009  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:schedule  [ cpu = 
> %(1)d, tasklet_scheduled = %(2)d, was_idle = %(3)d ]
> +0x0002200A  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:ratelimit [ 
> dom:vcpu = 0x%(1)04x%(2)04x, runtime = %(3)d ]
>  
>  0x00022201  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tick
>  0x00022202  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_pos   [ 
> dom:vcpu = 0x%(1)08x, pos = %(2)d]
> @@ -61,12 +65,16 @@
>  0x00022210  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:load_check [ 
> lrq_id[16]:orq_id[16] = 0x%(1)08x, delta = %(2)d ]
>  0x00022211  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:load_balance   [ 
> l_bavgload = 0x%(2)08x%(1)08x, o_bavgload = 0x%(4)08x%(3)08x, 
> lrq_id[16]:orq_id[16] = 0x%(5)08x ]
>  0x00022212  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:pick_cpu   [ 
> b_avgload = 0x%(2)08x%(1)08x, dom:vcpu = 0x%(3)08x, rq_id[16]:new_cpu[16] = 
> %(4)d ]
> +0x00022213  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_candidate [ 
> dom:vcpu = 0x%(1)08x, runq_pos = %(2)d tickled_cpu = %(3)d ]
> +0x00022214  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:schedule   [ 
> rq:cpu = 0x%(1)08x, tasklet[8]:idle[8]:smt_idle[8]:tickled[8] = %(2)08x ]
> +0x00022215  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:ratelimit  [ 
> dom:vcpu = 0x%(1)08x, runtime = %(2)d ]
>  
>  0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle[ cpu = 
> %(1)d ]
>  0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick [ 
> dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 
> 0x%(5)08x%(4)08x ]
>  0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ 
> dom:vcpu = 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
>  0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ 
> dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 
> 0x%(5)08x%(4)08x ]
>  0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
> +0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule  [ 
> cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
>  
>  0x00041001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_create   [ dom = 
> 0x%(1)08x ]
>  0x00041002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_destroy  [ dom = 
> 0x%(1)08x ]
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index 58a8d41..aaff1d9 100644
> --- a/tools/xentrace/xenalyze.c
> +++ b/tools/xentrace/xenalyze.c
> @@ -7590,6 +7590,50 @@ void sched_process(struct pcpu_info *p)
> ri->dump_header, r->cpu);
>  }
>  break;
> +case TRC_SCHED_CLASS_EVT(CSCHED, 7): /* BOOST_START   */
> +if(opt.dump_all) {
> +struct {
> +unsigned int domid, vcpuid;
> +} *r = (typeof(r))ri->d;
> +
> +printf(" %s csched: d%uv%u boosted\n",
> +   ri->dump_header, r->domid, r->vcpuid);
> +}
> +break;
> +case TRC_SCHED_CLASS_EVT(CSCHED, 8): /* BOOST_END */
> +if(opt.dump_all) {
> +struct {
> +unsigned int domid, vcpuid;
> +} *r = (typeof(r))ri->d;
> +
> +printf(" %s csched: d%uv%u unboosted\n",
> +   ri->dump_header, r->domid, r->vcpuid);
> +}
> +break;
> +case TRC_SCHED_CLASS_EVT(CSCHED, 9): /* SCHEDULE  */
> +if(opt.dump_all) {
> +struct {
> +   

Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> In both Credit2's trace records relative to checking
> whether we want to preempt a vcpu (in runq_tickle()),
> and to credits being burn, make it explicit on which
> pcpu the vcpu being considered is running.
> 
> Such information isn't currently available, not even
> by looking at on which pcpu the events happen, as we
> do both the above operation from a certain pcpu on
> vcpus running on different pcpus.

But you should be able to tell where a given vcpu is currently running
from the runstate changes, right?  Obviously xentrace_format couldn't
tell you that, but xenalyze should be able to, unless there were lost
trace records on the vcpu in question.

My modus operandi has been "try to keep trace volume from growing"
rather than "wait until trace volume is noticably an issue and reduce
it".  Presumably you've been doing a lot of tracing -- do you think I
should change my approach?

 -George


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

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

[Boris Ostrovsky]

On 09/19/2016 01:52 AM, Suravee Suthikulpanit wrote:
> GITHUB
> ==
> Latest git tree can be found at:
> http://github.com/ssuthiku/xen.gitxen_avic_part1_v1
>
> OVERVIEW
> 
> This patch set is the first of the two-part patch series to introduce 
> the new AMD Advance Virtual Interrupt Controller (AVIC) support.
>
> Basically, SVM AVIC hardware virtualizes local APIC registers of each
> vCPU via the virtual APIC (vAPIC) backing page. This allows guest access
> to certain APIC registers without the need to emulate the hardware behavior
> in the hypervisor. More information about AVIC can be found in the
> AMD64 Architecture Programmer’s Manual Volume 2 - System Programming.
>
>   http://support.amd.com/TechDocs/24593.pdf
>
> For SVM AVIC, we extend the existing kvm_amd driver to:
>   * Check CPUID to detect AVIC support in the processor
>   * Program new fields in VMCB to enable AVIC
>   * Introduce new AVIC data structures and add code to manage them
>   * Handle two new AVIC #VMEXITs
>   * Add new interrupt injection code using vAPIC backing page
> instead of the existing V_IRQ, V_INTR_PRIO, V_INTR_VECTOR,
> and V_IGN_TPR fields
>
> Currently, this patch series does not enable AVIC by default.
> Users can enable SVM AVIC by specifying Xen parameter svm-avic=1.
>
> Later, in part 2, we will introduce the IOMMU AVIC support, which
> provides speed up for PCI device pass-through use case by allowing
> the IOMMU hardware to inject interrupt directly into the guest via
> the vAPIC backing page.
>
> OVERALL PERFORMANCE
> ===
> Currently, AVIC is available on the AMD family 15h models 6Xh
> (Carrizo) processors and newer. Here, the Carizzo is used to collect
> performance data shown below.
>
> Generally, SVM AVIC alone (w/o IOMMU AVIC) should provide overall speed up
> for HVM guest since it does not require #vmexit into the hypervisor to
> emulate certain guest accesses to local APIC registers.
>
> It should also improve performance when hypervisor wants to inject
> interrupts into a running vcpu by setting the corresponded IRR
> bit in the vAPIC backing page and trigger AVIC_DOORBELL MSR.
>
> For sending IPI interrupts between running vcpus in Linux guest,
> Xen is default to using event channel.  However, in case of
> non-paravirtualize guest, AVIC can also provide performance
> improvements for sending IPI.
>
> BENCHMARK 1: HACKBENCH
> ==
>
> For measuring IPI performance used for scheduling workload, I have collected
> some performance number on 2 and 3 CPU running hackbech with the following
> detail:
>
>   hackbench -p -l 10
>   Running in process mode with 10 groups using 40 file descriptors each (== 
> 400 tasks)
>   Each sender will pass 10 messages of 100 bytes
>
>|  2 vcpus (sec) |  3 vcpus (sec)   
>   
> No AVIC w/o evtchn | 299.57 |337.779
> No AVIC w/  evtchn | 270.37 |419.6064 
>AVIC w/  evtchn | 181.46 |171.7957
>AVIC w/o evtchn | 171.81 |169.0858
>
> Note: In "w/o evtchn" case, the Linux guest is built w/o
>   Xen guest support.

Enlightened Linux tries to avoid using event channels for APIC accesses
if XEN_HVM_CPUID_APIC_ACCESS_VIRT or XEN_HVM_CPUID_X2APIC_VIRT is set.

I didn't notice either of these two bits set in the series. Should they
be (probably the first one)? Or is this something you are planning for
the second part?

-boris


>
> CURRENT UNTESTED USE-CASES
> ===
> - Nested VM
>
> Any feedback and comments are very much appreciated.
>
> Thank you,
> Suravee
>
> Suravee Suthikulpanit (9):
>   x86/HVM: Introduce struct hvm_pi_ops
>   x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as
> non-static
>   x86/HVM: Call vlapic_destroy after vcpu_destroy
>   x86/SVM: Modify VMCB fields to add AVIC support
>   x86/HVM/SVM: Add AVIC initialization code
>   x86/SVM: Add AVIC vmexit handlers
>   x86/SVM: Add vcpu scheduling support for AVIC
>   x86/SVM: Add interrupt management code via AVIC
>   x86/SVM: Hook up miscellaneous AVIC functions
>
>  xen/arch/x86/hvm/hvm.c |   4 +-
>  xen/arch/x86/hvm/svm/Makefile  |   1 +
>  xen/arch/x86/hvm/svm/avic.c| 609 
> +
>  xen/arch/x86/hvm/svm/intr.c|   4 +
>  xen/arch/x86/hvm/svm/svm.c |  57 +++-
>  xen/arch/x86/hvm/svm/vmcb.c|   9 +-
>  xen/arch/x86/hvm/vlapic.c  |   5 +-
>  xen/arch/x86/hvm/vmx/vmx.c |  32 +-
>  xen/include/asm-x86/hvm/domain.h   |  63 
>  xen/include/asm-x86/hvm/hvm.h  |   4 +-
>  xen/include/asm-x86/hvm/svm/avic.h |  49 +++
>  xen/include/asm-x86/hvm/svm/svm.h  |   2 +
>  xen/include/asm-x86/hvm/svm/vmcb.h |  35 ++-
>  xen/include/asm-x86/hvm/vlapic.h   |   4 +
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  59 
>  15 files changed, 843 insertions(+), 94 

[Xen-devel] [PATCH v4 2/4] libxl: add basic support for devices without backend

[Juergen Gross]

With the planned support of HVM USB passthrough via the USB emulation
capabilities of qemu libxl has to support guest devices which have no
back- and frontend. Information about those devices will live in the
libxl part of Xenstore only.

Add some basic support to libxl to be able to cope with this scenario.

Signed-off-by: Juergen Gross 
---
V4: corrected libxl__device_destroy() to not use be_path being NULL
---
 tools/libxl/libxl_device.c   | 70 
 tools/libxl/libxl_types_internal.idl |  1 +
 tools/libxl/libxl_xshelp.c   |  6 +++-
 3 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index dbf157d..1cc9098 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -114,15 +114,21 @@ int libxl__device_generic_add(libxl__gc *gc, 
xs_transaction_t t,
 libxl__device *device, char **bents, char **fents, char **ro_fents)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
-char *frontend_path, *backend_path, *libxl_path;
+char *frontend_path = NULL, *backend_path = NULL, *libxl_path;
 struct xs_permissions frontend_perms[2];
 struct xs_permissions ro_frontend_perms[2];
 struct xs_permissions backend_perms[2];
 int create_transaction = t == XBT_NULL;
+int libxl_only = device->backend_kind == LIBXL__DEVICE_KIND_NONE;
 int rc;
 
-frontend_path = libxl__device_frontend_path(gc, device);
-backend_path = libxl__device_backend_path(gc, device);
+if (libxl_only) {
+/* bents should be set as this is used to setup libxl_path content. */
+assert(!fents && !ro_fents);
+} else {
+frontend_path = libxl__device_frontend_path(gc, device);
+backend_path = libxl__device_backend_path(gc, device);
+}
 libxl_path = libxl__device_libxl_path(gc, device);
 
 frontend_perms[0].id = device->domid;
@@ -144,13 +150,15 @@ retry_transaction:
 rc = libxl__xs_rm_checked(gc, t, libxl_path);
 if (rc) goto out;
 
-rc = libxl__xs_write_checked(gc, t, GCSPRINTF("%s/frontend",libxl_path),
- frontend_path);
-if (rc) goto out;
+if (!libxl_only) {
+rc = libxl__xs_write_checked(gc, t, 
GCSPRINTF("%s/frontend",libxl_path),
+ frontend_path);
+if (rc) goto out;
 
-rc = libxl__xs_write_checked(gc, t, GCSPRINTF("%s/backend",libxl_path),
- backend_path);
-if (rc) goto out;
+rc = libxl__xs_write_checked(gc, t, GCSPRINTF("%s/backend",libxl_path),
+ backend_path);
+if (rc) goto out;
+}
 
 /* xxx much of this function lacks error checks! */
 
@@ -179,12 +187,15 @@ retry_transaction:
 }
 
 if (bents) {
-xs_rm(ctx->xsh, t, backend_path);
-xs_mkdir(ctx->xsh, t, backend_path);
-xs_set_permissions(ctx->xsh, t, backend_path, backend_perms, 
ARRAY_SIZE(backend_perms));
-xs_write(ctx->xsh, t, GCSPRINTF("%s/frontend", backend_path),
- frontend_path, strlen(frontend_path));
-libxl__xs_writev(gc, t, backend_path, bents);
+if (!libxl_only) {
+xs_rm(ctx->xsh, t, backend_path);
+xs_mkdir(ctx->xsh, t, backend_path);
+xs_set_permissions(ctx->xsh, t, backend_path, backend_perms,
+   ARRAY_SIZE(backend_perms));
+xs_write(ctx->xsh, t, GCSPRINTF("%s/frontend", backend_path),
+ frontend_path, strlen(frontend_path));
+libxl__xs_writev(gc, t, backend_path, bents);
+}
 
 /*
  * We make a copy of everything for the backend in the libxl
@@ -194,6 +205,9 @@ retry_transaction:
  * instead.  But there are still places in libxl that try to
  * reconstruct a config from xenstore.
  *
+ * For devices without PV backend (e.g. USB devices emulated via qemu)
+ * only the libxl path is written.
+ *
  * This duplication will typically produces duplicate keys
  * which will go out of date, but that's OK because nothing
  * reads those.  For example, there is usually
@@ -679,14 +693,21 @@ void libxl__multidev_prepared(libxl__egc *egc,
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-const char *be_path = libxl__device_backend_path(gc, dev);
-const char *fe_path = libxl__device_frontend_path(gc, dev);
+const char *be_path = NULL;
+const char *fe_path = NULL;
 const char *libxl_path = libxl__device_libxl_path(gc, dev);
-const char *tapdisk_path = GCSPRINTF("%s/%s", be_path, "tapdisk-params");
-const char *tapdisk_params;
+const char *tapdisk_path = NULL;
+const char *tapdisk_params = NULL;
 xs_transaction_t t = 0;
 int rc;
 uint32_t domid;
+int libxl_only = dev->backend_kind == LIBXL__DEVICE_KIND_NONE;
+
+if 

Re: [Xen-devel] [PATCH v4 2/4] libxl: add basic support for devices without backend

[Wei Liu]

On Tue, Sep 20, 2016 at 04:18:08PM +0200, Juergen Gross wrote:
> With the planned support of HVM USB passthrough via the USB emulation
> capabilities of qemu libxl has to support guest devices which have no
> back- and frontend. Information about those devices will live in the
> libxl part of Xenstore only.
> 
> Add some basic support to libxl to be able to cope with this scenario.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

[Derek Straka]

On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich  wrote:

> >>> On 20.09.16 at 14:35,  wrote:
> > On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich  wrote:
> >
> >> >>> On 13.09.16 at 21:40,  wrote:
> >> > Allows for the conditional inclusion of VGA driver on the x86 platform
> >> > rather than having it always enabled.
> >>
> >> So I guess with all three of these patches an overview mail is missing.
> >> What are you trying to accomplish? Solely reducing the binary size of
> >> Xen doesn't seem like a very important goal to me, and eliminating
> >> these drivers from the build doesn't appear to help make Xen more
> >> stable of secure.
> >>
> > I agree with your assessment on the stability and security standpoint.
> Our
> > customer has asked us to remove
> > unused drivers based on functionality of a set of boards.  Each of the
> > boards has a subset of the available hardware functionality
> > brought out to accessible headers.
>
> Well, does that mean that's just to reduce the size of the hypervisor?
> If so, I'm honestly not sure we want to set a precedent here, since
> if we do, people could come and suggest to make all sorts of code
> build conditionally, and I don't think our plans with Kconfig so far were
> going in that direction (but others may disagree with me here).
>
> For the most part: yes.  At the end of the day, my customer wants to
reduce the size of hypervisor.  I disagree a bit that these specific
changes
would set a poor precedent of for configuration.  The reason I proposed it
in the first place was the mechanisms for conditional compilation
were already implicitly available via HAS_*.  I thought adding the ability
for the user to explicitly define the configuration option
would be a permissible extension of the capability already present.  That
said, I do see your point about limiting the scope of conditional
code to avoid an eventual mess.  Thanks.

-Derek

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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Jan Beulich]

>>> On 08.09.16 at 18:21,  wrote:
> On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
>> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
>> typo-ed the source file name of the EFI map file install command.
> 
>  I really need Fedora to start building ld with PE support.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Konrad Rzeszutek Wilk 
>> 
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
>>  if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
>>  [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
>>  $(INSTALL_DATA) $(TARGET).efi 
>> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
>> -$(INSTALL_DATA) $(TARGET)-efi.map 
>> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map \
>> +$(INSTALL_DATA) $(TARGET).efi.map 
>> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \

Sadly this has further fallout: The file being installed here does not
exist in an ARM64 build. Can you please invent a fix for that?

Thanks, Jan


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

[Xen-devel] [PATCH] xen: switch to threaded irq in netback

[Juergen Gross]

Instead of open coding it use the threaded irq mechanism in
xen-netback.

Signed-off-by: Juergen Gross 
---
 drivers/net/xen-netback/common.h|  4 +---
 drivers/net/xen-netback/interface.c | 38 ++---
 drivers/net/xen-netback/netback.c   | 18 --
 3 files changed, 11 insertions(+), 49 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 84d6cbd..b38fb2c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -292,8 +292,6 @@ struct xenvif {
 #endif
 
struct xen_netif_ctrl_back_ring ctrl;
-   struct task_struct *ctrl_task;
-   wait_queue_head_t ctrl_wq;
unsigned int ctrl_irq;
 
/* Miscellaneous private stuff. */
@@ -359,7 +357,7 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
 
 int xenvif_dealloc_kthread(void *data);
 
-int xenvif_ctrl_kthread(void *data);
+irqreturn_t xenvif_ctrl_irq_fn(int irq, void *data);
 
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 83deeeb..fb50c6d 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -128,15 +128,6 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-irqreturn_t xenvif_ctrl_interrupt(int irq, void *dev_id)
-{
-   struct xenvif *vif = dev_id;
-
-   wake_up(>ctrl_wq);
-
-   return IRQ_HANDLED;
-}
-
 int xenvif_queue_stopped(struct xenvif_queue *queue)
 {
struct net_device *dev = queue->vif->dev;
@@ -570,8 +561,7 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t 
ring_ref,
struct net_device *dev = vif->dev;
void *addr;
struct xen_netif_ctrl_sring *shared;
-   struct task_struct *task;
-   int err = -ENOMEM;
+   int err;
 
err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
 _ref, 1, );
@@ -581,11 +571,7 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t 
ring_ref,
shared = (struct xen_netif_ctrl_sring *)addr;
BACK_RING_INIT(>ctrl, shared, XEN_PAGE_SIZE);
 
-   init_waitqueue_head(>ctrl_wq);
-
-   err = bind_interdomain_evtchn_to_irqhandler(vif->domid, evtchn,
-   xenvif_ctrl_interrupt,
-   0, dev->name, vif);
+   err = bind_interdomain_evtchn_to_irq(vif->domid, evtchn);
if (err < 0)
goto err_unmap;
 
@@ -593,19 +579,13 @@ int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t 
ring_ref,
 
xenvif_init_hash(vif);
 
-   task = kthread_create(xenvif_ctrl_kthread, (void *)vif,
- "%s-control", dev->name);
-   if (IS_ERR(task)) {
-   pr_warn("Could not allocate kthread for %s\n", dev->name);
-   err = PTR_ERR(task);
+   err = request_threaded_irq(vif->ctrl_irq, NULL, xenvif_ctrl_irq_fn,
+  IRQF_ONESHOT, "xen-netback-ctrl", vif);
+   if (err) {
+   pr_warn("Could not setup irq handler for %s\n", dev->name);
goto err_deinit;
}
 
-   get_task_struct(task);
-   vif->ctrl_task = task;
-
-   wake_up_process(vif->ctrl_task);
-
return 0;
 
 err_deinit:
@@ -774,12 +754,6 @@ void xenvif_disconnect_data(struct xenvif *vif)
 
 void xenvif_disconnect_ctrl(struct xenvif *vif)
 {
-   if (vif->ctrl_task) {
-   kthread_stop(vif->ctrl_task);
-   put_task_struct(vif->ctrl_task);
-   vif->ctrl_task = NULL;
-   }
-
if (vif->ctrl_irq) {
xenvif_deinit_hash(vif);
unbind_from_irqhandler(vif->ctrl_irq, vif);
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index edbae0b..3d0c989 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -2359,24 +2359,14 @@ static bool xenvif_ctrl_work_todo(struct xenvif *vif)
return 0;
 }
 
-int xenvif_ctrl_kthread(void *data)
+irqreturn_t xenvif_ctrl_irq_fn(int irq, void *data)
 {
struct xenvif *vif = data;
 
-   for (;;) {
-   wait_event_interruptible(vif->ctrl_wq,
-xenvif_ctrl_work_todo(vif) ||
-kthread_should_stop());
-   if (kthread_should_stop())
-   break;
+   while (xenvif_ctrl_work_todo(vif))
+   xenvif_ctrl_action(vif);
 
-   while (xenvif_ctrl_work_todo(vif))
-   xenvif_ctrl_action(vif);
-
-   cond_resched();
-   }
-
-   return 0;
+   return IRQ_HANDLED;
 }
 
 static int __init netback_init(void)
-- 
2.6.6


___
Xen-devel mailing list

[Xen-devel] [PATCH v4 1/4] libxl: add function to remove usb controller xenstore entries

[Juergen Gross]

In case of failure when trying to add a new USB controller to a domain
libxl might leak xenstore entries. Add a function to remove them and
call this function in case of failure.

Signed-off-by: Juergen Gross 
---
This patch might be a backport candidate to 4.7 (will have to modify
tools/libxl/libxl_pvusb.c instead).
---
 tools/libxl/libxl_usb.c | 58 +
 1 file changed, 44 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 6b30e0f..2493464 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -194,6 +194,47 @@ out:
 return rc;
 }
 
+static const char *vusb_be_from_xs_libxl(libxl__gc *gc, const char *libxl_path)
+{
+const char *be_path;
+int r;
+
+r = libxl__xs_read_checked(gc, XBT_NULL,
+   GCSPRINTF("%s/backend", libxl_path),
+   _path);
+if (r || !be_path) return NULL;
+
+return be_path;
+}
+
+static void libxl__device_usbctrl_del_xenstore(libxl__gc *gc, uint32_t domid,
+   libxl_device_usbctrl *usbctrl)
+{
+const char *libxl_path, *be_path;
+xs_transaction_t t = XBT_NULL;
+int rc;
+
+libxl_path = GCSPRINTF("%s/device/vusb/%d",
+   libxl__xs_libxl_path(gc, domid), usbctrl->devid);
+be_path = vusb_be_from_xs_libxl(gc, libxl_path);
+
+for (;;) {
+rc = libxl__xs_transaction_start(gc, );
+if (rc) goto out;
+
+libxl__xs_path_cleanup(gc, t, be_path);
+
+rc = libxl__xs_transaction_commit(gc, );
+if (!rc) break;
+if (rc < 0) goto out;
+}
+
+return;
+
+out:
+libxl__xs_transaction_abort(gc, );
+}
+
 static char *pvusb_get_device_type(libxl_usbctrl_type type)
 {
 switch (type) {
@@ -250,13 +291,15 @@ static void libxl__device_usbctrl_add(libxl__egc *egc, 
uint32_t domid,
 
 GCNEW(device);
 rc = libxl__device_from_usbctrl(gc, domid, usbctrl, device);
-if (rc) goto out;
+if (rc) goto outrm;
 
 aodev->dev = device;
 aodev->action = LIBXL__DEVICE_ACTION_ADD;
 libxl__wait_device_connection(egc, aodev);
 return;
 
+outrm:
+libxl__device_usbctrl_del_xenstore(gc, domid, usbctrl);
 out:
 aodev->rc = rc;
 aodev->callback(egc, aodev);
@@ -340,19 +383,6 @@ out:
 return;
 }
 
-static const char *vusb_be_from_xs_libxl(libxl__gc *gc, const char *libxl_path)
-{
-const char *be_path;
-int r;
-
-r = libxl__xs_read_checked(gc, XBT_NULL,
-   GCSPRINTF("%s/backend", libxl_path),
-   _path);
-if (r || !be_path) return NULL;
-
-return be_path;
-}
-
 libxl_device_usbctrl *
 libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-- 
2.6.6


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

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v4 02/21] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> But yes, I can split dsdt.asl as well. Should we keep _S5 definition as
> GPL-only?

I think once we're going down this route there is no benefit in trying
to argue for individual bits of code-that-was-once-Lenovo's that there
is no copyright interest.

So I would split those lines out as well.  That will mean multiple
includes.

Does iasl have a suitable conditional include syntax or are you going
to use `cat' or something in the Makefile ?

Ian.

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

[Xen-devel] [PATCH v4 0/4] libxl: add HVM USB passthrough capability

[Juergen Gross]

Add the capability to pass USB devices to HVM domains by using the
emulation of USB controllers of qemu.

The user interface via xl is the same as for pvusb passthrough, only
the type of the usbctrl is different: instead of "qusb" (qemu-based
pvusb backend) or "vusb" (kernel-based pvusb backend) the type
"devicemodel" is used.

Especially the communication with qemu via qmp commands is based on
the patches of George Dunlap sent in 2014:

https://lists.xen.org/archives/html/xen-devel/2014-06/msg00085.html

Changes in V4:
- patch 2: corrected libxl__device_destroy() to not use be_path being NULL

Changes in V3:
- patch 3: rename pvusb_get_port_path() to vusb_get_port_path()
  as requested by George Dunlap
- patch 4: wording adjusted as requested by Ian Jackson

Changes in V2:
- patches 1-3 removed as already pushed
- split out (new) patch 1 from patch 3 (was 5) as requested by Wei Liu
- addressed code style issues in patch 3 (was 5) as requested by Wei Liu
- added some assert()s n patch 3 (was 5) as requested by Wei Liu

Juergen Gross (4):
  libxl: add function to remove usb controller xenstore entries
  libxl: add basic support for devices without backend
  libxl: add HVM usb passthrough support
  docs: add HVM USB passthrough documentation

 docs/man/xl.cfg.pod.5.in |  12 +-
 tools/libxl/libxl_device.c   |  73 --
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_usb.c  | 435 +++
 tools/libxl/libxl_xshelp.c   |   6 +-
 tools/libxl/xl_cmdimpl.c |   4 +-
 6 files changed, 409 insertions(+), 122 deletions(-)

-- 
2.6.6


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

[Xen-devel] [PATCH v4 4/4] docs: add HVM USB passthrough documentation

[Juergen Gross]

Update the man page regarding passthrough of USB devices to HVM
domains via qemu USB emulation.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
V3: wording adjusted (Ian Jackson)
---
 docs/man/xl.cfg.pod.5.in | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 77a1be3..d8108e3 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -745,19 +745,29 @@ Specifies the usb controller type.
 
 "qusb" specifies a qemu base backend for pvusb.
 
+"devicemodel" specifies a USB controller emulated by qemu.
+It will show up as a PCI-device in the guest.
+
 "auto" (the default) determines whether a kernel based backend is installed.
 If this is the case, "pv" is selected, "qusb" will be selected if no kernel
 backend is currently available.
+For HVM domains "devicemodel" will be selected.
 
 =item 

[Xen-devel] [PATCH v4 3/4] libxl: add HVM usb passthrough support

[Juergen Gross]

Add HVM usb passthrough support to libxl by using qemu's capability
to emulate standard USB controllers.

A USB controller is added via qmp command to the emulated hardware
when a usbctrl device of type DEVICEMODEL is requested. Depending on
the requested speed the appropriate hardware type is selected. A host
USB device can then be added to the emulated USB controller via qmp
command.

Removing of the devices is done via qmp commands, too.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
V3: renamed pvusb_get_port_path() to vusb_get_port_path() (George Dunlap)

V2: code style issues (Wei Liu)
adding some assert()s (Wei Liu)
split out libxl__device_usbctrl_del_xenstore() (Wei Liu)
---
 tools/libxl/libxl_device.c |   3 +-
 tools/libxl/libxl_usb.c| 397 +++--
 tools/libxl/xl_cmdimpl.c   |   4 +-
 3 files changed, 311 insertions(+), 93 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 1cc9098..3e7a102 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -811,8 +811,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
libxl__devices_remove_state *drs)
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = dev;
 aodev->force = drs->force;
-if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
-dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
+if (dev->kind == LIBXL__DEVICE_KIND_VUSB)
 libxl__initiate_device_usbctrl_remove(egc, aodev);
 else
 libxl__initiate_device_generic_remove(egc, aodev);
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 2493464..76260b1 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -17,6 +17,7 @@
 
 #include "libxl_internal.h"
 #include 
+#include 
 
 #define USBBACK_INFO_PATH "/libxl/usbback"
 
@@ -43,12 +44,6 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
uint32_t domid,
 int rc;
 libxl_domain_type domtype = libxl__domain_type(gc, domid);
 
-if (!usbctrl->version)
-usbctrl->version = 2;
-
-if (!usbctrl->ports)
-usbctrl->ports = 8;
-
 if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) {
 if (domtype == LIBXL_DOMAIN_TYPE_PV) {
 rc = usbback_is_loaded(gc);
@@ -62,6 +57,71 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
uint32_t domid,
 }
 }
 
+switch (usbctrl->type) {
+case LIBXL_USBCTRL_TYPE_PV:
+case LIBXL_USBCTRL_TYPE_QUSB:
+if (!usbctrl->version)
+usbctrl->version = 2;
+if (usbctrl->version < 1 || usbctrl->version > 2) {
+LOG(ERROR,
+"USB version for paravirtualized devices must be 1 or 2");
+rc = ERROR_INVAL;
+goto out;
+}
+if (!usbctrl->ports)
+usbctrl->ports = 8;
+if (usbctrl->ports < 1 || usbctrl->ports > USBIF_MAX_PORTNR) {
+LOG(ERROR, "Number of ports for USB controller is limited to %u",
+USBIF_MAX_PORTNR);
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
+if (!usbctrl->version)
+usbctrl->version = 2;
+switch (usbctrl->version) {
+case 1:
+/* uhci controller in qemu has fixed number of ports. */
+if (usbctrl->ports && usbctrl->ports != 2) {
+LOG(ERROR,
+"Number of ports for USB controller of version 1 is always 
2");
+rc = ERROR_INVAL;
+goto out;
+}
+usbctrl->ports = 2;
+break;
+case 2:
+/* ehci controller in qemu has fixed number of ports. */
+if (usbctrl->ports && usbctrl->ports != 6) {
+LOG(ERROR,
+"Number of ports for USB controller of version 2 is always 
6");
+rc = ERROR_INVAL;
+goto out;
+}
+usbctrl->ports = 6;
+break;
+case 3:
+if (!usbctrl->ports)
+usbctrl->ports = 8;
+/* xhci controller in qemu supports up to 15 ports. */
+if (usbctrl->ports > 15) {
+LOG(ERROR,
+"Number of ports for USB controller of version 3 is 
limited to 15");
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+default:
+LOG(ERROR, "Illegal USB version");
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+default:
+break;
+}
+
 rc = libxl__resolve_domid(gc, usbctrl->backend_domname,
   >backend_domid);
 
@@ -75,9 +135,20 @@ static int libxl__device_from_usbctrl(libxl__gc *gc, 
uint32_t domid,
 {
 

Re: [Xen-devel] [PATCH 09/24] xen/tools: tracing: improve tracing of context switches.

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> Right now, two out of the three events related to
> context switch (that is TRC_SCHED_SWITCH_INFPREV and
> TRC_SCHED_SWITCH_INFNEXT) only report the domain id,
> and not the vcpu id.
> 
> That's omitting a useful piece of information, and
> even if we be figured that out by looking at other
> records, that's unnecessarily complicated (especially
> if working on a trace from a sctipt).
> 
> This changes both the tracing code in Xen and the parsing
> code in tools at once, to avoid introducing transitional
> regressions.
> 
> Signed-off-by: Dario Faggioli 

Hmm, I'm tempted to complain about the lack of packing; but in any case
I think these traces are redundant with the runstate change information,
so there's no need to be terribly picky. :-)

Acked-by: George Dunlap 

> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/xentrace/formats|4 ++--
>  tools/xentrace/xenalyze.c |   17 +
>  xen/common/schedule.c |8 
>  3 files changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/xentrace/formats b/tools/xentrace/formats
> index caafb5f..0de7990 100644
> --- a/tools/xentrace/formats
> +++ b/tools/xentrace/formats
> @@ -32,8 +32,8 @@
>  0x0002800b  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  s_timer_fn
>  0x0002800c  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  t_timer_fn
>  0x0002800d  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  dom_timer_fn
> -0x0002800e  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infprev[ 
> old_domid = 0x%(1)08x, runtime = %(2)d ]
> -0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext[ 
> new_domid = 0x%(1)08x, time = %(2)d, r_time = %(3)d ]
> +0x0002800e  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infprev[ dom:vcpu 
> = 0x%(1)04x%(2)04x, runtime = %(3)d ]
> +0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext[ 
> new_dom:vcpu = 0x%(1)04x%(2)04x, time = %(3)d, r_time = %(4)d ]
>  0x00028010  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_shutdown_code [ 
> dom:vcpu = 0x%(1)04x%(2)04x, reason = 0x%(3)08x ]
>  
>  0x00022001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:sched_tasklet
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index 11763a8..0b697d0 100644
> --- a/tools/xentrace/xenalyze.c
> +++ b/tools/xentrace/xenalyze.c
> @@ -7501,28 +7501,29 @@ void sched_process(struct pcpu_info *p)
>  case TRC_SCHED_SWITCH_INFPREV:
>  if(opt.dump_all) {
>  struct {
> -unsigned int domid, runtime;
> +unsigned int domid, vcpuid, runtime;
>  } *r = (typeof(r))ri->d;
>  
> -printf(" %s sched_switch prev d%u, run for %u.%uus\n",
> -   ri->dump_header, r->domid, r->runtime / 1000,
> -   r->runtime % 1000);
> +printf(" %s sched_switch prev d%uv%d, run for %u.%uus\n",
> +   ri->dump_header, r->domid, r->vcpuid,
> +   r->runtime / 1000, r->runtime % 1000);
>  }
>  break;
>  case TRC_SCHED_SWITCH_INFNEXT:
>  if(opt.dump_all)
>  {
>  struct {
> -unsigned int domid, rsince;
> +unsigned int domid, vcpuid, rsince;
>  int slice;
>  } *r = (typeof(r))ri->d;
>  
> -printf(" %s sched_switch next d%u", ri->dump_header, 
> r->domid);
> +printf(" %s sched_switch next d%uv%u", ri->dump_header,
> +   r->domid, r->vcpuid);
>  if ( r->rsince != 0 )
> -printf(", was runnable for %u.%uus, ", r->rsince / 1000,
> +printf(", was runnable for %u.%uus", r->rsince / 1000,
> r->rsince % 1000);
>  if ( r->slice > 0 )
> -printf("next slice %u.%uus", r->slice / 1000,
> +printf(", next slice %u.%uus", r->slice / 1000,
> r->slice % 1000);
>  printf("\n");
>  }
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index abe063d..5b444c4 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1390,11 +1390,11 @@ static void schedule(void)
>  return continue_running(prev);
>  }
>  
> -TRACE_2D(TRC_SCHED_SWITCH_INFPREV,
> - prev->domain->domain_id,
> +TRACE_3D(TRC_SCHED_SWITCH_INFPREV,
> + prev->domain->domain_id, prev->vcpu_id,
>   now - prev->runstate.state_entry_time);
> -TRACE_3D(TRC_SCHED_SWITCH_INFNEXT,
> - next->domain->domain_id,
> +TRACE_4D(TRC_SCHED_SWITCH_INFNEXT,
> + next->domain->domain_id, next->vcpu_id,
>   (next->runstate.state == 

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/20/2016 06:14 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("[PATCH v4 02/21] acpi: Prevent GPL-only code from 
> seeping into non-GPL binaries"):
>> Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
>> support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
>> GPLv2. We want to prevent this code from showing up in non-GPL
>> binaries which might become possible after we make ACPI builder code
>> available to users other than hvmloader.
>>
>> There are two pieces that we need to be careful about:
>> (1) A small piece of code in dsdt.asl that implements _PIC method
>> (2) A fragment of ASL generator in mk_dsdt.c that describes PCI
>> interrupt routing.
>>
>> The cleanest way to deal with this seems to be taking generatedi ASL
>> chunk from (2), adding it to dsdt.asl and keeping dsdt.asl GPL-only.
> This approach leaves us with the whole of dsdt.asl declared to be
> GPLv2.  If you are trying to relicence it as LGPLv2.1 this is not a
> good idea.
>
> Using this approach, if at some later point we get the missing ack
> from Lenovo, we would have to redo the licence review for the whole of
> dsdt.asl.  We would also have to ask Oracle's permission to relicense
> bits of the build system etc. !
>
> At the very least we should operate separate inbound/outbound
> licensing for this one file.
>
> But as I wrote on IRC, I think it would also be best to split out
> _just the troublesome portions_ into their own files, and include them
> at build time.  That way we have file-by-file source licensing.

I must have misunderstood you then, I thought we were talking only about
excising code from mk_dsdt.c.

But yes, I can split dsdt.asl as well. Should we keep _S5 definition as
GPL-only?

Lenovo patch was

+/* Poweroff support - ties in with qemu emulation */

+Name (\_S5, Package (0x04)
+{
+0x07,
+0x07,
+0x00,
+0x00
+})


and now it looks like

/* _S3 and _S4 are in separate SSDTs */
Name (\_S5, Package (0x04)
{
0x00,  /* PM1a_CNT.SLP_TYP */
0x00,  /* PM1b_CNT.SLP_TYP */
0x00,  /* reserved */
0x00   /* reserved */
})

My opinion is that using 0x7 would have been the original contribution
as the rest is is simply codifying what ACPI spec says. And since 0x7 is
no longer used we can re-license it together with the rest of dsdt.asl.


-boris


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

Re: [Xen-devel] [PATCH] tools: fix vif-route add|remove

[Wei Liu]

On Wed, Sep 07, 2016 at 09:52:31AM -0600, Charles Arnold wrote:
> From 2b4e942ad75f4a4546c417d8bd1116e3af368daf Mon Sep 17 00:00:00 2001
> From: Charles Arnold 
> Date: Wed, 7 Sep 2016 09:48:18 -0600
> Subject: [PATCH] tools: fix vif-route add|remove
> 
> vif-route is called twice. First for the vif interface and
> second for the vif-emu interface. vif-route takes 4 parameters,
> 
> (add|remove|online|offline)
> 
> When called with 'online|offline' then 'ipcmd' is set. When called
> with 'add|remove' then 'ipcmd' is empty ('') and the command,
> 
> ${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip}
> 
> will fail.
> 
> Signed-off-by: Charles Arnold 

OK, there is indeed a bug.

But do we need to do anything about add / remove? I suppose the script
works fine for you with this patch applied?

Wei.

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

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 20.09.16 at 12:52,  wrote:
> On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
>> >>> On 20.09.16 at 11:45,  wrote:
>> > On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
>> >> >>> On 19.09.16 at 17:04,  wrote:
>> >> > On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
>> >> >> >>> On 12.09.16 at 22:18,  wrote:
>> >> >> > --- a/xen/arch/x86/setup.c
>> >> >> > +++ b/xen/arch/x86/setup.c
>> >> >> > @@ -520,6 +520,8 @@ static void noinline init_done(void)
>> >> >> >
>> >> >> >  system_state = SYS_STATE_active;
>> >> >> >
>> >> >> > +free_ebmalloc_unused_mem();
>> >> >>
>> >> >> Now that the allocator properly lives in common code, this appears
>> >> >> to lack an ARM side counterpart.
>> >> >
>> >> > Why? It is called only from xen/arch/x86/setup.c:__start_xen() and all
>> >> > ebmalloc stuff is in #ifndef CONFIG_ARM. So, free_ebmalloc_unused_mem()
>> >> > will be needed only if we add ARM support here.
>> >>
>> >> Well, it being inside that conditional is part of the problem - there's
>> >> no apparent point for all of it to be.
>> >
>> > I can agree that this is potentially generic stuff (well, I understand that
>> > it is our final goal but unreachable yet due to various things). However,
>> > right know it is only used on x86. So, I am not sure what is the problem
>> > with #ifndef CONFIG_ARM right now...
>>
>> It is a fact that these should actually not be there, so we ought to
>> at least limit them to the smallest possible count and scopes.
>>
>> >> Arguably the one static function may better be, as other workarounds
>> >> to avoid the "unused" compiler warning wouldn't be any better.
>> >
>> > Do you mean static function with empty body for ARM? It is not needed
>> > right now because it is never called on ARM. Am I missing something?
>>
>> You misunderstood - I said that for this one (unused) static
>> function such an #ifdef is probably okay, as the presumably
>> smallest possible workaround.
> 
> Do you suggest that I should move out of #ifndef CONFIG_ARM all ebmalloc stuff
> except free_ebmalloc_unused_mem(). Even if it is not used on ARM right now?

That's not the static function, is it? The function you name should
actually be called on ARM too (as I did point out elsewhere already),
just to not leave a trap open for someone to fall into when (s)he
adds a first use of the allocator on ARM.

>> >> >> > +static unsigned long __initdata ebmalloc_allocated;
>> >> >> > +
>> >> >> > +/* EFI boot allocator. */
>> >> >> > +static void __init *ebmalloc(size_t size)
>> >> >> > +{
>> >> >> > +void *ptr = ebmalloc_mem + ebmalloc_allocated;
>> >> >> > +
>> >> >> > +ebmalloc_allocated += (size + sizeof(void *) - 1) & 
>> >> >> > ~((typeof(size))sizeof(void *) - 1);
>> >> >>
>> >> >> What's the point of this ugly cast?
>> >> >
>> >> > In general ALIGN_UP() would be nice here. However, there is no such 
>> >> > thing
>> >> > in Xen headers (or I cannot find it). Should I add one? As separate 
>> >> > patch?
>> >>
>> >> I understand what you want the expression for, but you didn't
>> >> answer my question. Or do you not realize that all this cast is
>> >> about is a strange way of converting an expression of type
>> >> size_t to type size_t?
>> >
>> > Does sizeof() returns size_t type? I was thinking that it returns
>> > a number calculated during compilation, however, it does not have
>> > specific type.
>>
>> Every expression needs to have a well specified type. Even
>> plain numbers do.
> 
> Hmmm... So, what is a type e.g. 5 without "U" and/or "L"? int?

Of course. But please may I ask you to read the spec instead?

Jan


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

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

[Jan Beulich]

>>> On 20.09.16 at 12:15,  wrote:
> On 09/20/2016 08:13 AM, Jan Beulich wrote:
> On 19.09.16 at 19:54,  wrote:
>>> On 09/19/2016 05:25 PM, Jan Beulich wrote:
>>> On 19.09.16 at 18:11,  wrote:
> On 09/19/2016 11:13 AM, Jan Beulich wrote:
> On 14.09.16 at 19:37,  wrote:
>>> Since b64438c7c ("x86/time: use correct (local) time stamp in
>>> constant-TSC calibration fast path") updates to cpu time use local
>>> stamps, which means platform timer is only used to seed the initial
>>> cpu time.  With clocksource=tsc there is no need to be in sync with
>>> another clocksource, so we reseed the local/master stamps to be values
>>> of TSC and update the platform time stamps accordingly. Time
>>> calibration is set to 1sec after we switch to TSC, thus these stamps
>>> are reseeded to also ensure monotonic returning values right after the
>>> point we switch to TSC. This is also to avoid the possibility of
>>> having inconsistent readings in this short period (i.e. until
>>> calibration fires).
>>
>> And within this one second, which may cover some of Dom0's
>> booting up, it is okay to have inconsistencies?
> It's not okay which is why I am removing this possibility when switching 
> to TSC.
> The inconsistencies in those readings (if I wasn't adjusting) would be 
> because
> we would be using (in that 1-sec) those cpu time tuples calculated by the
> previous calibration or platform time initialization (while still was 
> HPET,
> ACPI, etc as clocksource). Would you prefer me removing the "avoid" and 
> instead
> change it to "remove the possibility" in this last sentence?

 Let's not do the 2nd step before the 1st, which is the question of
 what happens prior to and what actually changes at this first
 calibration (after 1 sec).
>>> The first calibration won't change much - this 1-sec was meant when having
>>> nop_rendezvous which is the first time platform timer would be used to set 
>>> local
>>> cpu_time (will adjust the mention above as it's misleading for the reader 
>>> as it
>>> doesn't refer to this patch).
>> 
>> So what makes it that it actually _is_ nop_rendezvous after that one
>> second? (And yes, part of this may indeed be just bad placement of
>> the description, as iirc nop_rendezvous gets introduced only in a later
>> patch.)
> Because with nop_rendezvous we will be using the platform timer to get a
> monotonic time tuple and *set* cpu_time as opposed to just adding up plain TSC
> delta as it is the case prior to b64438c7c. Thus the reseeding of the cpu 
> times
> solves both ends of the problem, with nop_rendezvous until it is first
> calibration fixes it, and without nop_rendezvous to remove the latch 
> adjustment
> from initial platform timer.

So am I getting you right (together with the second part of your reply
further down) that you escape answering the question raised by saying
that it doesn't really matter which rendezvous function gets used, when
TSC is the clock source? I.e. the introduction of nop_rendezvous is
really just to avoid unnecessary overhead? In which case it should
probably be a separate patch, saying so in its description.

Jan


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

Re: [Xen-devel] [PATCH 08/24] xen: tracing: add trace records for schedule and rate-limiting.

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> As far as {csched, csched2, rt}_schedule() are concerned,
> an "empty" event, would already make it easier to read and
> understand a trace.
> 
> But while there, add a few useful information, like
> if the cpu that is going through the scheduler has
> been tickled or not, if it is currently idle, etc
> (they vary, on a per-scheduler basis).
> 
> For Credit1 and Credit2, add a record about when
> rate-limiting kicks in too.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Meng Xu 
> Cc: Anshul Makkar 
> ---
>  xen/common/sched_credit.c  |7 +++
>  xen/common/sched_credit2.c |   38 +-
>  xen/common/sched_rt.c  |   15 +++
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index ca04732..f9d3ac9 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -134,6 +134,8 @@
>  #define TRC_CSCHED_TICKLETRC_SCHED_CLASS_EVT(CSCHED, 6)
>  #define TRC_CSCHED_BOOST_START   TRC_SCHED_CLASS_EVT(CSCHED, 7)
>  #define TRC_CSCHED_BOOST_END TRC_SCHED_CLASS_EVT(CSCHED, 8)
> +#define TRC_CSCHED_SCHEDULE  TRC_SCHED_CLASS_EVT(CSCHED, 9)
> +#define TRC_CSCHED_RATELIMIT TRC_SCHED_CLASS_EVT(CSCHED, 10)
>  
>  
>  /*
> @@ -1743,6 +1745,9 @@ csched_schedule(
>  SCHED_STAT_CRANK(schedule);
>  CSCHED_VCPU_CHECK(current);
>  
> +TRACE_3D(TRC_CSCHED_SCHEDULE, cpu, tasklet_work_scheduled,
> + is_idle_vcpu(current));

Sorry to be annoying, but you're using two full words here for two bits
of information, and scheduling isn't exactly a once-every-few-seconds
phenomenon. :-)  Would you mind packing this in a bit?

> +
>  runtime = now - current->runstate.state_entry_time;
>  if ( runtime < 0 ) /* Does this ever happen? */
>  runtime = 0;
> @@ -1792,6 +1797,8 @@ csched_schedule(
>  snext->start_time += now;
>  perfc_incr(delay_ms);
>  tslice = MICROSECS(prv->ratelimit_us) - runtime;
> +TRACE_3D(TRC_CSCHED_RATELIMIT, scurr->vcpu->domain->domain_id,
> + scurr->vcpu->vcpu_id, runtime);

Same for this one, if you don't mind -- this one is less important
probably, but since you essentially have the code in credit2, it seems
like a pretty straightforward exercise to copy-and-paste it.

The credit2 traces look good -- thanks!

 -George


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

Re: [Xen-devel] [PATCH 06/24] xen: credit2: implement yield()

[George Dunlap]

On 20/09/16 14:25, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
>> When a vcpu explicitly yields it is usually giving
>> us an advice of "let someone else run and come back
>> to me in a bit."
>>
>> Credit2 isn't, so far, doing anything when a vcpu
>> yields, which means an yield is basically a NOP (well,
>> actually, it's pure overhead, as it causes the scheduler
>> kick in, but the result is --at least 99% of the time--
>> that the very same vcpu that yielded continues to run).
>>
>> Implement a "preempt bias", to be applied to yielding
>> vcpus. Basically when evaluating what vcpu to run next,
>> if a vcpu that has just yielded is encountered, we give
>> it a credit penalty, and check whether there is anyone
>> else that would better take over the cpu (of course,
>> if there isn't the yielding vcpu will continue).
>>
>> The value of this bias can be configured with a boot
>> time parameter, and the default is set to 1 ms.
>>
>> Also, add an yield performance counter, and fix the
>> style of a couple of comments.
>>
>> Signed-off-by: Dario Faggioli 
>> ---
>> Cc: George Dunlap 
>> Cc: Anshul Makkar 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> ---
>> Note that this *only* consider the bias during the very scheduling decision
>> that retults from the vcpu calling yield. After that, the __CSFLAG_vcpu_yield
>> flag is reset, and during all furute scheduling decisions, the vcpu will
>> compete with the other ones with its own amount of credits.
>>
>> Alternatively, we can actually _subtract_ some credits to a yielding vcpu.
>> That will sort of make the effect of a call to yield last in time.
>>
>> I'm not sure which path is best. Personally, I like the subtract approach
>> (perhaps, with a smaller bias than 1ms), but I think the "one shot" behavior
>> implemented here is a good starting point. It is _something_, which is better
>> than nothing, which is what we have without this patch! :-) It's lightweight
>> (in its impact on the crediting algorithm, I mean), and benchmarks looks 
>> nice,
>> so I propose we go for this one, and explore the "permanent" --subtraction
>> based-- solution a bit more.
>> ---
>>  docs/misc/xen-command-line.markdown |   10 ++
>>  xen/common/sched_credit2.c  |   62 
>> +++
>>  xen/common/schedule.c   |2 +
>>  xen/include/xen/perfc_defn.h|1 +
>>  4 files changed, 68 insertions(+), 7 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown 
>> b/docs/misc/xen-command-line.markdown
>> index 3a250cb..5f469b1 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1389,6 +1389,16 @@ Choose the default scheduler.
>>  ### sched\_credit2\_migrate\_resist
>>  > `= `
>>  
>> +### sched\_credit2\_yield\_bias
>> +> `= `
>> +
>> +> Default: `1000`
>> +
>> +Set how much a yielding vcpu will be penalized, in order to actually
>> +give a chance to run to some other vcpu. This is basically a bias, in
>> +favour of the non-yielding vcpus, expressed in microseconds (default
>> +is 1ms).
>> +
>>  ### sched\_credit\_tslice\_ms
>>  > `= `
>>  
>> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
>> index a3d7beb..569174b 100644
>> --- a/xen/common/sched_credit2.c
>> +++ b/xen/common/sched_credit2.c
>> @@ -144,6 +144,9 @@
>>  #define CSCHED2_MIGRATE_RESIST   ((opt_migrate_resist)*MICROSECS(1))
>>  /* How much to "compensate" a vcpu for L2 migration */
>>  #define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
>> +/* How big of a bias we should have against a yielding vcpu */
>> +#define CSCHED2_YIELD_BIAS   ((opt_yield_bias)*MICROSECS(1))
>> +#define CSCHED2_YIELD_BIAS_MIN   CSCHED2_MIN_TIMER
>>  /* Reset: Value below which credit will be reset. */
>>  #define CSCHED2_CREDIT_RESET 0
>>  /* Max timer: Maximum time a guest can be run for. */
>> @@ -181,11 +184,20 @@
>>   */
>>  #define __CSFLAG_runq_migrate_request 3
>>  #define CSFLAG_runq_migrate_request (1<<__CSFLAG_runq_migrate_request)
>> -
>> +/*
>> + * CSFLAG_vcpu_yield: this vcpu was running, and has called vcpu_yield(). 
>> The
>> + * scheduler is invoked to see if we can give the cpu to someone else, and
>> + * get back to the yielding vcpu in a while.
>> + */
>> +#define __CSFLAG_vcpu_yield 4
>> +#define CSFLAG_vcpu_yield (1<<__CSFLAG_vcpu_yield)
>>  
>>  static unsigned int __read_mostly opt_migrate_resist = 500;
>>  integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
>>  
>> +static unsigned int __read_mostly opt_yield_bias = 1000;
>> +integer_param("sched_credit2_yield_bias", opt_yield_bias);
>> +
>>  /*
>>   * Useful macros
>>   */
>> @@ -1432,6 +1444,14 @@ out:
>>  }
>>  
>>  static void
>> +csched2_vcpu_yield(const struct scheduler *ops, struct vcpu *v)
>> +{
>> +struct csched2_vcpu * const svc = 

[Xen-devel] [distros-debian-snapshot test] 67732: trouble: blocked/broken/pass

[Platform Team regression test user]

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

Failures and problems with tests :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-amd64-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-current-netinst-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-daily-netboot-pvgrub  1 build-check(1)blocked n/a
 test-amd64-i386-i386-weekly-netinst-pygrub  1 build-check(1)   blocked n/a
 test-amd64-i386-amd64-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 test-amd64-i386-i386-current-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-weekly-netinst-pygrub  1 build-check(1) blocked n/a

baseline version:
 flight   67704

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  blocked 
 test-amd64-i386-i386-daily-netboot-pvgrubblocked 
 test-amd64-i386-amd64-daily-netboot-pygrub   blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   blocked 
 test-amd64-amd64-amd64-current-netinst-pygrubblocked 
 test-amd64-i386-amd64-current-netinst-pygrub blocked 
 test-amd64-amd64-i386-current-netinst-pygrub blocked 
 test-amd64-i386-i386-current-netinst-pygrub  blocked 
 test-amd64-amd64-amd64-weekly-netinst-pygrub blocked 
 test-amd64-i386-amd64-weekly-netinst-pygrub  blocked 
 test-amd64-amd64-i386-weekly-netinst-pygrub  blocked 
 test-amd64-i386-i386-weekly-netinst-pygrub   blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 07/24] xen: sched: don't rate limit context switches in case of yields

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> In both Credit1 and Credit2, if a vcpu yields, let it...
> well... yield!
> 
> In fact, context switch rate limiting has been primarily
> introduced to avoid too heavy context switch rate due to
> interrupts, and, in general, asynchronous events.
> 
> In a vcpu "voluntarily" yields, we really should let it
> give up the cpu for a while. For instance, the reason may
> be that it's about to start spinning, and there's few
> point in forcing a vcpu to spin for (potentially) the
> entire rate-limiting period.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> ---
>  xen/common/sched_credit.c  |   20 +++
>  xen/common/sched_credit2.c |   47 
> +++-
>  2 files changed, 37 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 3f439a0..ca04732 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1771,9 +1771,18 @@ csched_schedule(
>   *   cpu and steal it.
>   */
>  
> -/* If we have schedule rate limiting enabled, check to see
> - * how long we've run for. */
> -if ( !tasklet_work_scheduled
> +/*
> + * If we have schedule rate limiting enabled, check to see
> + * how long we've run for.
> + *
> + * If scurr is yielding, however, we don't let rate limiting kick in.
> + * In fact, it may be the case that scurr is about to spin, and there's
> + * no point forcing it to do so until rate limiting expires.
> + *
> + * While there, take the chance for clearing the yield flag at once.
> + */
> +if ( !test_and_clear_bit(CSCHED_FLAG_VCPU_YIELD, >flags)

It looks like YIELD is implemented by putting it lower in the runqueue
in __runqueue_insert().  But here you're clearing the flag before the
insert happens -- won't this effectively disable yield() for credit1?


> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 569174b..c8e0ee7 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -2267,36 +2267,40 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>  struct list_head *iter;
>  struct csched2_vcpu *snext = NULL;
>  struct csched2_private *prv = CSCHED2_PRIV(per_cpu(scheduler, cpu));
> -int yield_bias = 0;
> -
> -/* Default to current if runnable, idle otherwise */
> -if ( vcpu_runnable(scurr->vcpu) )
> -{
> -/*
> - * The way we actually take yields into account is like this:
> - * if scurr is yielding, when comparing its credits with other
> - * vcpus in the runqueue, act like those other vcpus had yield_bias
> - * more credits.
> - */
> -if ( unlikely(scurr->flags & CSFLAG_vcpu_yield) )
> -yield_bias = CSCHED2_YIELD_BIAS;
> -
> -snext = scurr;
> -}
> -else
> -snext = CSCHED2_VCPU(idle_vcpu[cpu]);
> +/*
> + * The way we actually take yields into account is like this:
> + * if scurr is yielding, when comparing its credits with other vcpus in
> + * the runqueue, act like those other vcpus had yield_bias more credits.
> + */
> +int yield_bias = __test_and_clear_bit(__CSFLAG_vcpu_yield, 
> >flags) ?
> + CSCHED2_YIELD_BIAS : 0;
>  
>  /*
>   * Return the current vcpu if it has executed for less than ratelimit.
>   * Adjuststment for the selected vcpu's credit and decision
>   * for how long it will run will be taken in csched2_runtime.
> + *
> + * Note that, if scurr is yielding, we don't let rate limiting kick in.
> + * In fact, it may be the case that scurr is about to spin, and there's
> + * no point forcing it to do so until rate limiting expires.
> + *
> + * To check whether we are yielding, it's enough to look at yield_bias
> + * (as CSCHED2_YIELD_BIAS can't be zero). Also, note that the yield flag
> + * has been cleared already above.
>   */
> -if ( prv->ratelimit_us && !is_idle_vcpu(scurr->vcpu) &&
> +if ( !yield_bias &&
> + prv->ratelimit_us && !is_idle_vcpu(scurr->vcpu) &&
>   vcpu_runnable(scurr->vcpu) &&
>   (now - scurr->vcpu->runstate.state_entry_time) <
>MICROSECS(prv->ratelimit_us) )
>  return scurr;
>  
> +/* Default to current if runnable, idle otherwise */
> +if ( vcpu_runnable(scurr->vcpu) )
> +snext = scurr;
> +else
> +snext = CSCHED2_VCPU(idle_vcpu[cpu]);

This looks good, but the code re-organization probably goes better in
the previous patch.  Since you're re-sending anyway, would you mind
moving it there?

I'm not sure the credit2 yield-ratelimit needs to be in a separate
patch; since you're implementing yield in credit2 from scratch you could
just implement it all in one go.  But since you have 

[Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

>From 97760602b5c94745e76ed78d23e8fdf9988d234e Mon Sep 17 00:00:00 2001
From: Quan Xu 
Date: Tue, 20 Sep 2016 21:12:54 +0800
Subject: [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

When Xen apicv is enabled, wall clock time is faster on Windows7-32
guest with high payload (with 2vCPU, captured from xentrace, in
high payload, the count of IPI interrupt increases rapidly between
these vCPUs).

If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pending (index of bit set in vIRR), unfortunately, the IPI
intrrupt is high priority than periodic timer interrupt. Xen updates
IPI interrupt bit set in vIRR to guest interrupt status (RVI) as a high
priority and apicv (Virtual-Interrupt Delivery) delivers IPI interrupt
within VMX non-root operation without a VM-Exit. Within VMX non-root
operation, if periodic timer interrupt index of bit is set in vIRR and
highest, the apicv delivers periodic timer interrupt within VMX non-root
operation as well.

But in current code, if Xen doesn't update periodic timer interrupt bit
set in vIRR to guest interrupt status (RVI) directly, Xen is not aware
of this case to decrease the count (pending_intr_nr) of pending periodic
timer interrupt, then Xen will deliver a periodic timer interrupt again.

And that we update periodic timer interrupt in every VM-entry, there is
a chance that already-injected instance (before EOI-induced exit happens)
will incur another pending IRR setting if there is a VM-exit happens
between virtual interrupt injection (vIRR->0, vISR->1) and EOI-induced
exit (vISR->0), since pt_intr_post hasn't been invoked yet, then the
guest receives more periodic timer interrupt.

So change to pt_intr_post in EOI-induced exit handler and skip periodic
timer when it is not be completely consumed (irq_issued is ture).

Signed-off-by: Yifei Jiang 
Signed-off-by: Rongguang He 
Signed-off-by: Quan Xu 

---
v2:
  -change to pt_intr_post in EOI-induced exit handler.
  -skip periodic timer when it is not be completely consumed
   (irq_issued is ture).
---
 xen/arch/x86/hvm/vlapic.c   | 6 ++
 xen/arch/x86/hvm/vmx/intr.c | 2 --
 xen/arch/x86/hvm/vpt.c  | 3 ++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 1d5d287..f83d6ab 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
 void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
 {
 struct domain *d = vlapic_domain(vlapic);
+struct vcpu *v = vlapic_vcpu(vlapic);
+struct hvm_intack pt_intack;
+
+pt_intack.vector = vector;
+pt_intack.source = hvm_intsrc_lapic;
+pt_intr_post(v, pt_intack);

 if ( vlapic_test_and_clear_vector(vector, >regs->data[APIC_TMR]) )
 vioapic_update_EOI(d, vector);
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 8fca08c..29d9bbf 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -333,8 +333,6 @@ void vmx_intr_assist(void)
 clear_bit(i, >arch.hvm_vmx.eoi_exitmap_changed);
 __vmwrite(EOI_EXIT_BITMAP(i), v->arch.hvm_vmx.eoi_exit_bitmap[i]);
 }
-
-pt_intr_post(v, intack);
 }
 else
 {
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index 5c48fdb..a9da436 100644
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -252,7 +252,8 @@ int pt_update_irq(struct vcpu *v)
 }
 else
 {
-if ( (pt->last_plt_gtime + pt->period) < max_lag )
+if ( (pt->last_plt_gtime + pt->period) < max_lag &&
+ !pt->irq_issued )
 {
 max_lag = pt->last_plt_gtime + pt->period;
 earliest_pt = pt;
--
1.8.3.4



0001-x86-apicv-fix-RTC-periodic-timer-and-apicv-issue.patch
Description: 0001-x86-apicv-fix-RTC-periodic-timer-and-apicv-issue.patch
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

[Jan Beulich]

>>> On 20.09.16 at 13:43,  wrote:
> On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote:
>> >>> On 19.09.16 at 15:56,  wrote:
>> > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote:
>> >> >>> On 16.09.16 at 22:43,  wrote:
>> >> > On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
>> >> In particular
>> >> I can't see why __2M_rwdata_end (aliased to efi) does not relate to
>> >> the intended image end. Once we switch back to using large pages
>> >> even when not using xen.efi I'd even question whether preferring
>> >> _end over __2M_rwdata_end is actually correct.
>> >
>> > This is good question. I was thinking about that after posting v6. It seems
>> > that from image POV _end is correct. However, taking into account that Xen
>> > image mapping covers 16 MiB then I think we should use __2M_rwdata_end (or
>> > define __end_of_image__ symbol equal to __2M_rwdata_end). This way boot
>> > loader will allocate memory region for Xen image later covered properly by
>> > mapping, nothing will be put in memory immediately after the Xen image and
>> > later incorrectly mapped as Xen image.
> 
> Current xen image p_memsz does not end at 16 MiB. It seems to me that this is
> incorrect. Should I fix it? It looks that we just have to move out .pad of
> #ifdef EFI. Are you OK with it?

Just to emphasize again: I'm okay with any fix which actually fixes
something. I continue to be unconvinced there is something that
actually needs fixing. So as long as you can properly explain what
is wrong, I won't stand in the way of your change going in. For the
case here this means - if the value is e.g. off by a few bytes, then
I don't see an issue. This 16Mb boundary isn't a hard one anyway.
If otoh the value is off by an arbitrary amount, which just happens
to be small enough in most cases, then I do see a need for a change.

Jan


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

Re: [Xen-devel] [PATCH 06/24] xen: credit2: implement yield()

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> When a vcpu explicitly yields it is usually giving
> us an advice of "let someone else run and come back
> to me in a bit."
> 
> Credit2 isn't, so far, doing anything when a vcpu
> yields, which means an yield is basically a NOP (well,
> actually, it's pure overhead, as it causes the scheduler
> kick in, but the result is --at least 99% of the time--
> that the very same vcpu that yielded continues to run).
> 
> Implement a "preempt bias", to be applied to yielding
> vcpus. Basically when evaluating what vcpu to run next,
> if a vcpu that has just yielded is encountered, we give
> it a credit penalty, and check whether there is anyone
> else that would better take over the cpu (of course,
> if there isn't the yielding vcpu will continue).
> 
> The value of this bias can be configured with a boot
> time parameter, and the default is set to 1 ms.
> 
> Also, add an yield performance counter, and fix the
> style of a couple of comments.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> Note that this *only* consider the bias during the very scheduling decision
> that retults from the vcpu calling yield. After that, the __CSFLAG_vcpu_yield
> flag is reset, and during all furute scheduling decisions, the vcpu will
> compete with the other ones with its own amount of credits.
> 
> Alternatively, we can actually _subtract_ some credits to a yielding vcpu.
> That will sort of make the effect of a call to yield last in time.
> 
> I'm not sure which path is best. Personally, I like the subtract approach
> (perhaps, with a smaller bias than 1ms), but I think the "one shot" behavior
> implemented here is a good starting point. It is _something_, which is better
> than nothing, which is what we have without this patch! :-) It's lightweight
> (in its impact on the crediting algorithm, I mean), and benchmarks looks nice,
> so I propose we go for this one, and explore the "permanent" --subtraction
> based-- solution a bit more.
> ---
>  docs/misc/xen-command-line.markdown |   10 ++
>  xen/common/sched_credit2.c  |   62 
> +++
>  xen/common/schedule.c   |2 +
>  xen/include/xen/perfc_defn.h|1 +
>  4 files changed, 68 insertions(+), 7 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 3a250cb..5f469b1 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1389,6 +1389,16 @@ Choose the default scheduler.
>  ### sched\_credit2\_migrate\_resist
>  > `= `
>  
> +### sched\_credit2\_yield\_bias
> +> `= `
> +
> +> Default: `1000`
> +
> +Set how much a yielding vcpu will be penalized, in order to actually
> +give a chance to run to some other vcpu. This is basically a bias, in
> +favour of the non-yielding vcpus, expressed in microseconds (default
> +is 1ms).
> +
>  ### sched\_credit\_tslice\_ms
>  > `= `
>  
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index a3d7beb..569174b 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -144,6 +144,9 @@
>  #define CSCHED2_MIGRATE_RESIST   ((opt_migrate_resist)*MICROSECS(1))
>  /* How much to "compensate" a vcpu for L2 migration */
>  #define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
> +/* How big of a bias we should have against a yielding vcpu */
> +#define CSCHED2_YIELD_BIAS   ((opt_yield_bias)*MICROSECS(1))
> +#define CSCHED2_YIELD_BIAS_MIN   CSCHED2_MIN_TIMER
>  /* Reset: Value below which credit will be reset. */
>  #define CSCHED2_CREDIT_RESET 0
>  /* Max timer: Maximum time a guest can be run for. */
> @@ -181,11 +184,20 @@
>   */
>  #define __CSFLAG_runq_migrate_request 3
>  #define CSFLAG_runq_migrate_request (1<<__CSFLAG_runq_migrate_request)
> -
> +/*
> + * CSFLAG_vcpu_yield: this vcpu was running, and has called vcpu_yield(). The
> + * scheduler is invoked to see if we can give the cpu to someone else, and
> + * get back to the yielding vcpu in a while.
> + */
> +#define __CSFLAG_vcpu_yield 4
> +#define CSFLAG_vcpu_yield (1<<__CSFLAG_vcpu_yield)
>  
>  static unsigned int __read_mostly opt_migrate_resist = 500;
>  integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
>  
> +static unsigned int __read_mostly opt_yield_bias = 1000;
> +integer_param("sched_credit2_yield_bias", opt_yield_bias);
> +
>  /*
>   * Useful macros
>   */
> @@ -1432,6 +1444,14 @@ out:
>  }
>  
>  static void
> +csched2_vcpu_yield(const struct scheduler *ops, struct vcpu *v)
> +{
> +struct csched2_vcpu * const svc = CSCHED2_VCPU(v);
> +
> +__set_bit(__CSFLAG_vcpu_yield, >flags);
> +}
> +
> +static void
>  csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
>  {
>  

Re: [Xen-devel] [PATCH v3 3/4] libxl: add HVM usb passthrough support

[Wei Liu]

On Tue, Sep 20, 2016 at 02:01:09PM +0200, Juergen Gross wrote:
> Add HVM usb passthrough support to libxl by using qemu's capability
> to emulate standard USB controllers.
> 
> A USB controller is added via qmp command to the emulated hardware
> when a usbctrl device of type DEVICEMODEL is requested. Depending on
> the requested speed the appropriate hardware type is selected. A host
> USB device can then be added to the emulated USB controller via qmp
> command.
> 
> Removing of the devices is done via qmp commands, too.
> 
> Signed-off-by: Juergen Gross 
> ---
> V3: renamed pvusb_get_port_path() to vusb_get_port_path() (George Dunlap)

Nothing substantial is changed, so:

Acked-by: Wei Liu 

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

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

[Jan Beulich]

>>> On 20.09.16 at 14:11,  wrote:
> On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote:
>> >>> On 14.09.16 at 10:23,  wrote:
>> > Additionally, my investigation has shown that there are no bound checks in
>> > low memory allocation machinery for trampoline (by the way, in BIOS path we
>> > allocate 64 KiB for trampoline but in EFI code we properly calculate its 
>> > size;
>> > so, I think we should do the same calculation in BIOS path), stack and 
>> > boot data
>> > taken from multiboot protocol. Hence, relevant fixes should be added here 
>> > too.
>>
>> Would be nice, yes, but we need to weigh the need to presumably do
>> at least some of this in assembly code (for now at least) against the
>> potential gain.
>>
>> > Moreover I think that at least allocation machinery with additional checks
>> > described in last paragraph can be used on EFI platforms when Xen is booted
>> > via multiboot2 protocol. However, then high limit should be defined as 1 
>> > MiB.
>> > Though I think that low limit, 256 KiB, should stay as is.
>>
>> Why 1Mb? The 640k limit derives from hardware aspects, but doesn't
>> depend on the software environment.
> 
> I do not expect that anything which is not memory will reside between 640 KiB
> and 1 MiB on EFI platforms. So, if firmware says that it is usable why we 
> cannot
> use it? And I have a feeling that this idea lead to currently existing checks
> around trampoline allocation code for EFI. Though, as I saw EFI platforms
> usually does not expose region 640 KiB and 1 MiB as usable. However, this
> does not mean that they cannot in the future.

Hmm, when the region (or part of it) is reported as available, then I
guess we could use it. But as to there being RAM - I doubt it, since
for the next little while, EFI or not, we're talking about PC compatible
systems, which don't normally have RAM in that range.

>> > So, I think that we should prepare following patches:
>> >   - allocate properly calculated amount of memory for trampoline,
>> >   - define high/low limit as a constants and use them,
>> >   - add bounds checks for chosen low memory region, and bounds
>> > checks in allocation machinery for trampoline and stack,
>> >   - add bounds checks to allocator in reloc.c.
>> >
>> > I have a feeling that this fixes are not very critical, however, nice to 
>> > have.
>>
>> Indeed. I'd just like to avoid that new code (read: your mb2 series)
>> gets introduced with similar issues. Just like the original EFI code at
>> least tries to properly allocate the trampoline space.
> 
> OK, I have a feeling that you wish to postpone most of proposed changes for 
> later.
> I can understand that. However, if we wish check that there is sufficient 
> amount
> of memory available for trampoline we should decide which value to use. Should
> we use 64 KiB from BIOS Xen assembly code or trampoline real size like in Xen
> EFI code? Trampoline real size is much more sensible for me but this requires
> some changes in assembly code allocating trampoline.

Why? Current EFI code uses the actual size too. Hence I think you
could do so as well in your new additions, leaving the legacy code
alone until you or someone else means to overhaul it.

> We can allocate trampoline
> real size on both EFI and BIOS platforms. Or leave BIOS case as is and use
> trampoline real size just only on EFI platforms.

Exactly.

Jan


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

[Xen-devel] [ vTPM ] ownership disappear

[Ernesto Valentino]

Hi everyone,
when I create a vTPM instance and attached to it a VM, I use tpm-tools to
take thw ownership of the vTPM. Then, if I destroy the vTPM and the VM, my
expectation is that when I re-create the same vTPM attached to the same VM,
the owership is already taken, but this is not the case: if I re-run
tpm_takeownership, the command is successfull. Why this happens?

Thank you!

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

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

[Jan Beulich]

>>> On 20.09.16 at 14:35,  wrote:
> On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich  wrote:
> 
>> >>> On 13.09.16 at 21:40,  wrote:
>> > Allows for the conditional inclusion of VGA driver on the x86 platform
>> > rather than having it always enabled.
>>
>> So I guess with all three of these patches an overview mail is missing.
>> What are you trying to accomplish? Solely reducing the binary size of
>> Xen doesn't seem like a very important goal to me, and eliminating
>> these drivers from the build doesn't appear to help make Xen more
>> stable of secure.
>>
> I agree with your assessment on the stability and security standpoint.  Our
> customer has asked us to remove
> unused drivers based on functionality of a set of boards.  Each of the
> boards has a subset of the available hardware functionality
> brought out to accessible headers.

Well, does that mean that's just to reduce the size of the hypervisor?
If so, I'm honestly not sure we want to set a precedent here, since
if we do, people could come and suggest to make all sorts of code
build conditionally, and I don't think our plans with Kconfig so far were
going in that direction (but others may disagree with me here).

Jan


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

Re: [Xen-devel] [PATCH] Fix issues introduced in 3a7f872a

[Wei Liu]

On Tue, Sep 20, 2016 at 01:18:35PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] Fix issues introduced in 3a7f872a"):
> > 3a7f872a ("tools: lift BUILD_BUG_ON to a tools header file") was taken
> > out from an rather old half finished branch by dropping unrelated
> > changes.  Unfortunately two issues sneaked in.
> > 
> > 1. Hvmloader should be standalone. Revert the changes to hvmloader.
> > 2. The define guard in libs.h was erroneously deleted. Add that back.
> 
> Sorry, I didn't realise you were waiting for my ack.
> 
> Acked-by: Ian Jackson 
> 

Pushed. Thanks everyone.

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

[Xen-devel] [PATCH] VMX: don't bypass vmx_update_secondary_exec_control()

[Jan Beulich]

While putting together another patch modifying the secondary exec
controls I noticed that vmx_vcpu_update_vmfunc_ve() does a raw VMWRITE
instead of going through the designated function. I assume that is not
how it should be.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2062,9 +2062,7 @@ static void vmx_vcpu_update_vmfunc_ve(st
 else
 v->arch.hvm_vmx.secondary_exec_control &= ~mask;
 
-__vmwrite(SECONDARY_VM_EXEC_CONTROL,
-  v->arch.hvm_vmx.secondary_exec_control);
-
+vmx_update_secondary_exec_control(v);
 vmx_vmcs_exit(v);
 }
 



VMX: don't bypass vmx_update_secondary_exec_control()

While putting together another patch modifying the secondary exec
controls I noticed that vmx_vcpu_update_vmfunc_ve() does a raw VMWRITE
instead of going through the designated function. I assume that is not
how it should be.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2062,9 +2062,7 @@ static void vmx_vcpu_update_vmfunc_ve(st
 else
 v->arch.hvm_vmx.secondary_exec_control &= ~mask;
 
-__vmwrite(SECONDARY_VM_EXEC_CONTROL,
-  v->arch.hvm_vmx.secondary_exec_control);
-
+vmx_update_secondary_exec_control(v);
 vmx_vmcs_exit(v);
 }
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.5-testing test] 101024: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 100909
 build-i3865 xen-buildfail REGR. vs. 100909

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 101015 pass in 101024
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 101015

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 100909
 test-armhf-armhf-xl-rtds 11 guest-start fail in 101015 like 100909

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)  

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

[Derek Straka]

On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich  wrote:

> >>> On 13.09.16 at 21:40,  wrote:
> > Allows for the conditional inclusion of VGA driver on the x86 platform
> > rather than having it always enabled.
>
> So I guess with all three of these patches an overview mail is missing.
> What are you trying to accomplish? Solely reducing the binary size of
> Xen doesn't seem like a very important goal to me, and eliminating
> these drivers from the build doesn't appear to help make Xen more
> stable of secure.
>
I agree with your assessment on the stability and security standpoint.  Our
customer has asked us to remove
unused drivers based on functionality of a set of boards.  Each of the
boards has a subset of the available hardware functionality
brought out to accessible headers.  I decided to try to make these items
optional via the Kconfig mechanisms already
in place in Xen and contribute the modifications upstream.  I appreciate
all of the feedback on the patches, but if they won't
get accepted upstream because they aren't useful, I don't want to continue
to waste people's time reviewing these changes.

-Derek

>
> > @@ -672,6 +675,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >
> >  printk("Command line: %s\n", cmdline);
> >
> > +#ifdef CONFIG_VGA
> >  printk("Video information:\n");
>
> Some of the other conditionals you add may be affected too, but
> here it is most prominent at the first glance - considering that we also
> have CONFIG_VIDEO, wouldn't it rather be that one to be used in a
> place like this one?
>
> > --- a/xen/include/xen/console.h
> > +++ b/xen/include/xen/console.h
> > @@ -19,7 +19,15 @@ void console_init_postirq(void);
> >  void console_endboot(void);
> >  int console_has(const char *device);
> >
> > +#ifdef CONFIG_VGA
> >  int fill_console_start_info(struct dom0_vga_console_info *);
> > +#else
> > +#include 
> > +static inline int fill_console_start_info(struct dom0_vga_console_info
> *ci)
> > {
> > +(void) memset(ci, 0, sizeof(*ci));
>
> What is this cast to void goo for?
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Fix issues introduced in 3a7f872a

[Ian Jackson]

Wei Liu writes ("[PATCH] Fix issues introduced in 3a7f872a"):
> 3a7f872a ("tools: lift BUILD_BUG_ON to a tools header file") was taken
> out from an rather old half finished branch by dropping unrelated
> changes.  Unfortunately two issues sneaked in.
> 
> 1. Hvmloader should be standalone. Revert the changes to hvmloader.
> 2. The define guard in libs.h was erroneously deleted. Add that back.

Sorry, I didn't realise you were waiting for my ack.

Acked-by: Ian Jackson 

Ian.

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

[Xen-devel] [xen-4.7-testing test] 101022: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 101013 pass in 101022
 test-armhf-armhf-xl-multivcpu  5 xen-install   fail pass in 101013

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

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

version targeted for testing:
 xen  317eb71bc3b0830338601fb14d1f49546a1c1e35
baseline version:
 xen  038aadd63752baf18b7cc9c7fbec0e5f3aa7c46a

Last test of basis   100905  2016-09-12 23:40:57 Z7 days
Testing same since   101013  2016-09-19 15:45:51 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Marek Marczykowski-Górecki 
  Stefan Bader 
  Wei Liu 

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

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

[Dario Faggioli]

On Tue, 2016-09-20 at 12:20 +0100, George Dunlap wrote:
> On 20/09/16 03:31, Dongli Zhang wrote:
> > 
> > This patch implemented parts of TODO left in commit id
> > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush
> > filtering in alloc_heap_pages()). It moved TLB-flush filtering out
> > into
> > populate_physmap. Because of TLB-flush in alloc_heap_pages, it's
> > very slow
> > to create a guest with memory size of more than 100GB on host with
> > 100+
> > cpus.
> > 
> > This patch introduced a "MEMF_no_tlbflush" bit to memflags to
> > indicate
> > whether TLB-flush should be done in alloc_heap_pages or its caller
> > populate_physmap.  Once this bit is set in memflags,
> > alloc_heap_pages will
> > ignore TLB-flush. To use this bit after vm is created might lead to
> > security issue, that is, this would make pages accessible to the
> > guest B,
> > when guest A may still have a cached mapping to them.
> > 
> > Therefore, this patch also introduced a "creation_finished" field
> > to struct
> > domain to indicate whether this domain has ever got unpaused by
> > hypervisor.
> > MEMF_no_tlbflush can be set only during vm creation phase when
> > creation_finished is still false before this domain gets unpaused
> > for the
> > first time.
> > 
> > Signed-off-by: Dongli Zhang 
> 
> Acked-by: George Dunlap 
> 
FWIW, and if I'm still in time:

Reviewed-by: Dario Faggioli 

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

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

On Tue, 2016-09-20 at 12:19 +0100, George Dunlap wrote:
> On 20/09/16 03:31, Dongli Zhang wrote:
> > 
> > This patch cleaned up the code by replacing complicated tlbflush
> > check and
> > operation with inline functions. We should use those inline
> > functions to
> > avoid the complicated tlbflush check and tlbflush operations when
> > implementing TODOs left in commit
> > a902c12ee45fc9389eb8fe54eeddaf267a555c58
> > (More efficient TLB-flush filtering in alloc_heap_pages()).
> > 
> > "#include " is removed from
> > xen/arch/x86/acpi/suspend.c to
> > avoid the compiling error after we include "" to
> > xen/include/xen/mm.h.
> > 
> > Signed-off-by: Dongli Zhang 
> 
> Acked-by: George Dunlap 
> 
Reviewed-by: Dario Faggioli 

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

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

[Daniel Kiper]

On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote:
> >>> On 14.09.16 at 10:23,  wrote:
> > Starting from the beginning it looks that there are "soft" limits enforced
> > in BIOS early boot code looking for usable low memory region. Hight limit
> > is set at 640 KiB and low at 256 KiB. This means that if a value from a 
> > given
> > source which describes low memory region (i.e. EBDA base segment, base 
> > memory
> > size, multiboot protocol) is out of bounds then we try to get new value from
> > next one (I mean source). However, at the end there are no checks that 
> > assure
> > us that we got what we expected. So, I think that at first we should add 
> > "hard"
> > checks here. This means that if we get value out of earlier mentioned bounds
> > then we should print relevant message on serial console and halt the system.
>
> I disagree. I think that the best effort approach (what you name "soft"
> checks) are quite okay in the legacy BIOS case: Even if the BIOS has
> screwed things up, we can still _try_ to come up nevertheless.
>
> This is quite different for (imo) much more sophisticated EFI
> environments: We know they are screwed too, but we can't as
> easily ignore them using certain pieces of memory.
>
> > Additionally, my investigation has shown that there are no bound checks in
> > low memory allocation machinery for trampoline (by the way, in BIOS path we
> > allocate 64 KiB for trampoline but in EFI code we properly calculate its 
> > size;
> > so, I think we should do the same calculation in BIOS path), stack and boot 
> > data
> > taken from multiboot protocol. Hence, relevant fixes should be added here 
> > too.
>
> Would be nice, yes, but we need to weigh the need to presumably do
> at least some of this in assembly code (for now at least) against the
> potential gain.
>
> > Moreover I think that at least allocation machinery with additional checks
> > described in last paragraph can be used on EFI platforms when Xen is booted
> > via multiboot2 protocol. However, then high limit should be defined as 1 
> > MiB.
> > Though I think that low limit, 256 KiB, should stay as is.
>
> Why 1Mb? The 640k limit derives from hardware aspects, but doesn't
> depend on the software environment.

I do not expect that anything which is not memory will reside between 640 KiB
and 1 MiB on EFI platforms. So, if firmware says that it is usable why we cannot
use it? And I have a feeling that this idea lead to currently existing checks
around trampoline allocation code for EFI. Though, as I saw EFI platforms
usually does not expose region 640 KiB and 1 MiB as usable. However, this
does not mean that they cannot in the future.

> > So, I think that we should prepare following patches:
> >   - allocate properly calculated amount of memory for trampoline,
> >   - define high/low limit as a constants and use them,
> >   - add bounds checks for chosen low memory region, and bounds
> > checks in allocation machinery for trampoline and stack,
> >   - add bounds checks to allocator in reloc.c.
> >
> > I have a feeling that this fixes are not very critical, however, nice to 
> > have.
>
> Indeed. I'd just like to avoid that new code (read: your mb2 series)
> gets introduced with similar issues. Just like the original EFI code at
> least tries to properly allocate the trampoline space.

OK, I have a feeling that you wish to postpone most of proposed changes for 
later.
I can understand that. However, if we wish check that there is sufficient amount
of memory available for trampoline we should decide which value to use. Should
we use 64 KiB from BIOS Xen assembly code or trampoline real size like in Xen
EFI code? Trampoline real size is much more sensible for me but this requires
some changes in assembly code allocating trampoline. We can allocate trampoline
real size on both EFI and BIOS platforms. Or leave BIOS case as is and use
trampoline real size just only on EFI platforms.

Daniel

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

[Xen-devel] [PATCH v3 0/4] libxl: add HVM USB passthrough capability

[Juergen Gross]

Add the capability to pass USB devices to HVM domains by using the
emulation of USB controllers of qemu.

The user interface via xl is the same as for pvusb passthrough, only
the type of the usbctrl is different: instead of "qusb" (qemu-based
pvusb backend) or "vusb" (kernel-based pvusb backend) the type
"devicemodel" is used.

Especially the communication with qemu via qmp commands is based on
the patches of George Dunlap sent in 2014:

https://lists.xen.org/archives/html/xen-devel/2014-06/msg00085.html

Changes in V3:
- patch 3: rename pvusb_get_port_path() to vusb_get_port_path()
  as requested by George Dunlap
- patch 4: wording adjusted as requested by Ian Jackson

Changes in V2:
- patches 1-3 removed as already pushed
- split out (new) patch 1 from patch 3 (was 5) as requested by Wei Liu
- addressed code style issues in patch 3 (was 5) as requested by Wei Liu
- added some assert()s n patch 3 (was 5) as requested by Wei Liu

Juergen Gross (4):
  libxl: add function to remove usb controller xenstore entries
  libxl: add basic support for devices without backend
  libxl: add HVM usb passthrough support
  docs: add HVM USB passthrough documentation

 docs/man/xl.cfg.pod.5.in |  12 +-
 tools/libxl/libxl_device.c   |  62 +++--
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_usb.c  | 435 +++
 tools/libxl/libxl_xshelp.c   |   6 +-
 tools/libxl/xl_cmdimpl.c |   4 +-
 6 files changed, 402 insertions(+), 118 deletions(-)

-- 
2.6.6


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

[Xen-devel] [PATCH v3 3/4] libxl: add HVM usb passthrough support

[Juergen Gross]

Add HVM usb passthrough support to libxl by using qemu's capability
to emulate standard USB controllers.

A USB controller is added via qmp command to the emulated hardware
when a usbctrl device of type DEVICEMODEL is requested. Depending on
the requested speed the appropriate hardware type is selected. A host
USB device can then be added to the emulated USB controller via qmp
command.

Removing of the devices is done via qmp commands, too.

Signed-off-by: Juergen Gross 
---
V3: renamed pvusb_get_port_path() to vusb_get_port_path() (George Dunlap)

V2: code style issues (Wei Liu)
adding some assert()s (Wei Liu)
split out libxl__device_usbctrl_del_xenstore() (Wei Liu)
---
 tools/libxl/libxl_device.c |   3 +-
 tools/libxl/libxl_usb.c| 397 +++--
 tools/libxl/xl_cmdimpl.c   |   4 +-
 3 files changed, 311 insertions(+), 93 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index f53f772..2acfb48 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -808,8 +808,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
libxl__devices_remove_state *drs)
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = dev;
 aodev->force = drs->force;
-if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
-dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
+if (dev->kind == LIBXL__DEVICE_KIND_VUSB)
 libxl__initiate_device_usbctrl_remove(egc, aodev);
 else
 libxl__initiate_device_generic_remove(egc, aodev);
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 2493464..76260b1 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -17,6 +17,7 @@
 
 #include "libxl_internal.h"
 #include 
+#include 
 
 #define USBBACK_INFO_PATH "/libxl/usbback"
 
@@ -43,12 +44,6 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
uint32_t domid,
 int rc;
 libxl_domain_type domtype = libxl__domain_type(gc, domid);
 
-if (!usbctrl->version)
-usbctrl->version = 2;
-
-if (!usbctrl->ports)
-usbctrl->ports = 8;
-
 if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) {
 if (domtype == LIBXL_DOMAIN_TYPE_PV) {
 rc = usbback_is_loaded(gc);
@@ -62,6 +57,71 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
uint32_t domid,
 }
 }
 
+switch (usbctrl->type) {
+case LIBXL_USBCTRL_TYPE_PV:
+case LIBXL_USBCTRL_TYPE_QUSB:
+if (!usbctrl->version)
+usbctrl->version = 2;
+if (usbctrl->version < 1 || usbctrl->version > 2) {
+LOG(ERROR,
+"USB version for paravirtualized devices must be 1 or 2");
+rc = ERROR_INVAL;
+goto out;
+}
+if (!usbctrl->ports)
+usbctrl->ports = 8;
+if (usbctrl->ports < 1 || usbctrl->ports > USBIF_MAX_PORTNR) {
+LOG(ERROR, "Number of ports for USB controller is limited to %u",
+USBIF_MAX_PORTNR);
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
+if (!usbctrl->version)
+usbctrl->version = 2;
+switch (usbctrl->version) {
+case 1:
+/* uhci controller in qemu has fixed number of ports. */
+if (usbctrl->ports && usbctrl->ports != 2) {
+LOG(ERROR,
+"Number of ports for USB controller of version 1 is always 
2");
+rc = ERROR_INVAL;
+goto out;
+}
+usbctrl->ports = 2;
+break;
+case 2:
+/* ehci controller in qemu has fixed number of ports. */
+if (usbctrl->ports && usbctrl->ports != 6) {
+LOG(ERROR,
+"Number of ports for USB controller of version 2 is always 
6");
+rc = ERROR_INVAL;
+goto out;
+}
+usbctrl->ports = 6;
+break;
+case 3:
+if (!usbctrl->ports)
+usbctrl->ports = 8;
+/* xhci controller in qemu supports up to 15 ports. */
+if (usbctrl->ports > 15) {
+LOG(ERROR,
+"Number of ports for USB controller of version 3 is 
limited to 15");
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+default:
+LOG(ERROR, "Illegal USB version");
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+default:
+break;
+}
+
 rc = libxl__resolve_domid(gc, usbctrl->backend_domname,
   >backend_domid);
 
@@ -75,9 +135,20 @@ static int libxl__device_from_usbctrl(libxl__gc *gc, 
uint32_t domid,
 {
 device->backend_devid   = usbctrl->devid;
   

[Xen-devel] [PATCH v3 2/4] libxl: add basic support for devices without backend

[Juergen Gross]

With the planned support of HVM USB passthrough via the USB emulation
capabilities of qemu libxl has to support guest devices which have no
back- and frontend. Information about those devices will live in the
libxl part of Xenstore only.

Add some basic support to libxl to be able to cope with this scenario.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_device.c   | 59 
 tools/libxl/libxl_types_internal.idl |  1 +
 tools/libxl/libxl_xshelp.c   |  6 +++-
 3 files changed, 46 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index dbf157d..f53f772 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -114,15 +114,21 @@ int libxl__device_generic_add(libxl__gc *gc, 
xs_transaction_t t,
 libxl__device *device, char **bents, char **fents, char **ro_fents)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
-char *frontend_path, *backend_path, *libxl_path;
+char *frontend_path = NULL, *backend_path = NULL, *libxl_path;
 struct xs_permissions frontend_perms[2];
 struct xs_permissions ro_frontend_perms[2];
 struct xs_permissions backend_perms[2];
 int create_transaction = t == XBT_NULL;
+int libxl_only = device->backend_kind == LIBXL__DEVICE_KIND_NONE;
 int rc;
 
-frontend_path = libxl__device_frontend_path(gc, device);
-backend_path = libxl__device_backend_path(gc, device);
+if (libxl_only) {
+/* bents should be set as this is used to setup libxl_path content. */
+assert(!fents && !ro_fents);
+} else {
+frontend_path = libxl__device_frontend_path(gc, device);
+backend_path = libxl__device_backend_path(gc, device);
+}
 libxl_path = libxl__device_libxl_path(gc, device);
 
 frontend_perms[0].id = device->domid;
@@ -144,13 +150,15 @@ retry_transaction:
 rc = libxl__xs_rm_checked(gc, t, libxl_path);
 if (rc) goto out;
 
-rc = libxl__xs_write_checked(gc, t, GCSPRINTF("%s/frontend",libxl_path),
- frontend_path);
-if (rc) goto out;
+if (!libxl_only) {
+rc = libxl__xs_write_checked(gc, t, 
GCSPRINTF("%s/frontend",libxl_path),
+ frontend_path);
+if (rc) goto out;
 
-rc = libxl__xs_write_checked(gc, t, GCSPRINTF("%s/backend",libxl_path),
- backend_path);
-if (rc) goto out;
+rc = libxl__xs_write_checked(gc, t, GCSPRINTF("%s/backend",libxl_path),
+ backend_path);
+if (rc) goto out;
+}
 
 /* xxx much of this function lacks error checks! */
 
@@ -179,12 +187,15 @@ retry_transaction:
 }
 
 if (bents) {
-xs_rm(ctx->xsh, t, backend_path);
-xs_mkdir(ctx->xsh, t, backend_path);
-xs_set_permissions(ctx->xsh, t, backend_path, backend_perms, 
ARRAY_SIZE(backend_perms));
-xs_write(ctx->xsh, t, GCSPRINTF("%s/frontend", backend_path),
- frontend_path, strlen(frontend_path));
-libxl__xs_writev(gc, t, backend_path, bents);
+if (!libxl_only) {
+xs_rm(ctx->xsh, t, backend_path);
+xs_mkdir(ctx->xsh, t, backend_path);
+xs_set_permissions(ctx->xsh, t, backend_path, backend_perms,
+   ARRAY_SIZE(backend_perms));
+xs_write(ctx->xsh, t, GCSPRINTF("%s/frontend", backend_path),
+ frontend_path, strlen(frontend_path));
+libxl__xs_writev(gc, t, backend_path, bents);
+}
 
 /*
  * We make a copy of everything for the backend in the libxl
@@ -194,6 +205,9 @@ retry_transaction:
  * instead.  But there are still places in libxl that try to
  * reconstruct a config from xenstore.
  *
+ * For devices without PV backend (e.g. USB devices emulated via qemu)
+ * only the libxl path is written.
+ *
  * This duplication will typically produces duplicate keys
  * which will go out of date, but that's OK because nothing
  * reads those.  For example, there is usually
@@ -679,14 +693,20 @@ void libxl__multidev_prepared(libxl__egc *egc,
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-const char *be_path = libxl__device_backend_path(gc, dev);
-const char *fe_path = libxl__device_frontend_path(gc, dev);
+const char *be_path = NULL;
+const char *fe_path = NULL;
 const char *libxl_path = libxl__device_libxl_path(gc, dev);
 const char *tapdisk_path = GCSPRINTF("%s/%s", be_path, "tapdisk-params");
 const char *tapdisk_params;
 xs_transaction_t t = 0;
 int rc;
 uint32_t domid;
+int libxl_only = dev->backend_kind == LIBXL__DEVICE_KIND_NONE;
+
+if (!libxl_only) {
+be_path = libxl__device_backend_path(gc, dev);
+fe_path = 

[Xen-devel] [PATCH v3 1/4] libxl: add function to remove usb controller xenstore entries

[Juergen Gross]

In case of failure when trying to add a new USB controller to a domain
libxl might leak xenstore entries. Add a function to remove them and
call this function in case of failure.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
This patch might be a backport candidate to 4.7 (will have to modify
tools/libxl/libxl_pvusb.c instead).
---
 tools/libxl/libxl_usb.c | 58 +
 1 file changed, 44 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 6b30e0f..2493464 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -194,6 +194,47 @@ out:
 return rc;
 }
 
+static const char *vusb_be_from_xs_libxl(libxl__gc *gc, const char *libxl_path)
+{
+const char *be_path;
+int r;
+
+r = libxl__xs_read_checked(gc, XBT_NULL,
+   GCSPRINTF("%s/backend", libxl_path),
+   _path);
+if (r || !be_path) return NULL;
+
+return be_path;
+}
+
+static void libxl__device_usbctrl_del_xenstore(libxl__gc *gc, uint32_t domid,
+   libxl_device_usbctrl *usbctrl)
+{
+const char *libxl_path, *be_path;
+xs_transaction_t t = XBT_NULL;
+int rc;
+
+libxl_path = GCSPRINTF("%s/device/vusb/%d",
+   libxl__xs_libxl_path(gc, domid), usbctrl->devid);
+be_path = vusb_be_from_xs_libxl(gc, libxl_path);
+
+for (;;) {
+rc = libxl__xs_transaction_start(gc, );
+if (rc) goto out;
+
+libxl__xs_path_cleanup(gc, t, be_path);
+
+rc = libxl__xs_transaction_commit(gc, );
+if (!rc) break;
+if (rc < 0) goto out;
+}
+
+return;
+
+out:
+libxl__xs_transaction_abort(gc, );
+}
+
 static char *pvusb_get_device_type(libxl_usbctrl_type type)
 {
 switch (type) {
@@ -250,13 +291,15 @@ static void libxl__device_usbctrl_add(libxl__egc *egc, 
uint32_t domid,
 
 GCNEW(device);
 rc = libxl__device_from_usbctrl(gc, domid, usbctrl, device);
-if (rc) goto out;
+if (rc) goto outrm;
 
 aodev->dev = device;
 aodev->action = LIBXL__DEVICE_ACTION_ADD;
 libxl__wait_device_connection(egc, aodev);
 return;
 
+outrm:
+libxl__device_usbctrl_del_xenstore(gc, domid, usbctrl);
 out:
 aodev->rc = rc;
 aodev->callback(egc, aodev);
@@ -340,19 +383,6 @@ out:
 return;
 }
 
-static const char *vusb_be_from_xs_libxl(libxl__gc *gc, const char *libxl_path)
-{
-const char *be_path;
-int r;
-
-r = libxl__xs_read_checked(gc, XBT_NULL,
-   GCSPRINTF("%s/backend", libxl_path),
-   _path);
-if (r || !be_path) return NULL;
-
-return be_path;
-}
-
 libxl_device_usbctrl *
 libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
-- 
2.6.6


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

[Xen-devel] [PATCH v3 4/4] docs: add HVM USB passthrough documentation

[Juergen Gross]

Update the man page regarding passthrough of USB devices to HVM
domains via qemu USB emulation.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
V3: wording adjusted (Ian Jackson)
---
 docs/man/xl.cfg.pod.5.in | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 77a1be3..d8108e3 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -745,19 +745,29 @@ Specifies the usb controller type.
 
 "qusb" specifies a qemu base backend for pvusb.
 
+"devicemodel" specifies a USB controller emulated by qemu.
+It will show up as a PCI-device in the guest.
+
 "auto" (the default) determines whether a kernel based backend is installed.
 If this is the case, "pv" is selected, "qusb" will be selected if no kernel
 backend is currently available.
+For HVM domains "devicemodel" will be selected.
 
 =item 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
baseline version:
 ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42

Last test of basis   100969  2016-09-15 14:44:47 Z4 days
Testing same since   101025  2016-09-20 01:49:01 Z0 days1 attempts


People who touched revisions under test:
  Hegde Nagaraj P 
  Jiaxin Wu 

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=0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
+ . ./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 
0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
+ branch=ovmf
+ revision=0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
+ . ./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.7-testing
+ '[' x0a92ac8802704d7281ff7b9bc00ec4f893c3ece2 = 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
++ :