flight 9471 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9471/
Regressions :-(
Tests which did not succeed and are blocking:
test-i386-i386-pair 20 leak-check/check/src_host fail REGR. vs. 9355
test-i386-i386-pair 21 leak-check/check/dst_host fail REGR. vs. 9355
test-amd64-i386-xl-credit2 12 guest-saverestore.2 fail REGR. vs. 9355
test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 9355
test-amd64-amd64-win 7 windows-install fail REGR. vs. 9355
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pv 13 guest-localmigrate.2 fail pass in 9363
test-amd64-i386-pv 12 guest-saverestore.2 fail pass in 9363
test-i386-i386-xl-win 7 windows-install fail pass in 9363
test-amd64-amd64-xl-win 7 windows-install fail pass in 9363
test-amd64-amd64-pair 21 leak-check/check/dst_host fail in 9363 pass in 9471
test-amd64-amd64-pair 20 leak-check/check/src_host fail in 9363 pass in 9471
test-amd64-i386-xl-win-vcpus1 7 windows-install fail in 9363 pass in 9471
test-amd64-i386-win 7 windows-install fail in 9363 pass in 9471
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 13 guest-stop fail in 9363 never pass
test-amd64-amd64-xl-win 13 guest-stop fail in 9363 never pass
version targeted for testing:
xen a7ccbc79fc17
baseline version:
xen 6c583d35d76d
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@xxxxxxxx>
Keir Fraser <keir@xxxxxxx>
Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
Tim Deegan <tim@xxxxxxx>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair broken
test-amd64-amd64-pv fail
test-amd64-i386-pv fail
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 23991:a7ccbc79fc17
tag: tip
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:45:24 2011 +0200
cpumask <=> xenctl_cpumap: allocate CPU masks and byte maps dynamically
Generally there was a NR_CPUS-bits wide array in these functions and
another (through a cpumask_t) on their callers' stacks, which may get
a little large for big NR_CPUS. As the functions can fail anyway, do
the allocation in there.
For the x86/MCA case this require a little code restructuring: By using
different CPU mask accessors it was possible to avoid allocating a mask
in the broadcast case. Also, this was the only user that failed to
check the return value of the conversion function (which could have led
to undefined behvior).
Also constify the input parameters of the two functions.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23990:1c8789852eaf
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:44:47 2011 +0200
x86/hpet: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23989:8269826353d8
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:44:03 2011 +0200
credit: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23988:53528bab2eb4
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:43:35 2011 +0200
cpupools: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23987:2682094bc243
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:42:47 2011 +0200
x86/p2m: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Tim Deegan <tim@xxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
--- 2011-10-18.orig/xen/arch/x86/hvm/nestedhvm.c 2011-10-11
17:24:46.000000000 +0200
+++ 2011-10-18/xen/arch/x86/hvm/nestedhvm.c 2011-10-18 16:45:02.000000000
+0200
@@ -114,9 +114,9 @@ nestedhvm_flushtlb_ipi(void *info)
void
nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
{
- on_selected_cpus(&p2m->p2m_dirty_cpumask, nestedhvm_flushtlb_ipi,
+ on_selected_cpus(p2m->dirty_cpumask, nestedhvm_flushtlb_ipi,
p2m->domain, 1);
- cpumask_clear(&p2m->p2m_dirty_cpumask);
+ cpumask_clear(p2m->dirty_cpumask);
}
bool_t
--- 2011-10-18.orig/xen/arch/x86/mm/hap/nested_hap.c 2011-10-21
09:24:51.000000000 +0200
+++ 2011-10-18/xen/arch/x86/mm/hap/nested_hap.c 2011-10-18
16:44:35.000000000 +0200
@@ -88,7 +88,7 @@ nestedp2m_write_p2m_entry(struct p2m_dom
safe_write_pte(p, new);
if (old_flags & _PAGE_PRESENT)
- flush_tlb_mask(&p2m->p2m_dirty_cpumask);
+ flush_tlb_mask(p2m->dirty_cpumask);
paging_unlock(d);
}
--- 2011-10-18.orig/xen/arch/x86/mm/p2m.c 2011-10-14 09:47:46.000000000
+0200
+++ 2011-10-18/xen/arch/x86/mm/p2m.c 2011-10-21 09:28:33.000000000
+0200
@@ -81,7 +81,6 @@ static void p2m_initialise(struct domain
p2m->default_access = p2m_access_rwx;
p2m->cr3 = CR3_EADDR;
- cpumask_clear(&p2m->p2m_dirty_cpumask);
if ( hap_enabled(d) && (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
ept_p2m_init(p2m);
@@ -102,6 +101,8 @@ p2m_init_nestedp2m(struct domain *d)
d->arch.nested_p2m[i] = p2m = xzalloc(struct p2m_domain);
if (p2m == NULL)
return -ENOMEM;
+ if ( !zalloc_cpumask_var(&p2m->dirty_cpumask) )
+ return -ENOMEM;
p2m_initialise(d, p2m);
p2m->write_p2m_entry = nestedp2m_write_p2m_entry;
list_add(&p2m->np2m_list, &p2m_get_hostp2m(d)->np2m_list);
@@ -118,6 +119,11 @@ int p2m_init(struct domain *d)
p2m_get_hostp2m(d) = p2m = xzalloc(struct p2m_domain);
if ( p2m == NULL )
return -ENOMEM;
+ if ( !zalloc_cpumask_var(&p2m->dirty_cpumask) )
+ {
+ xfree(p2m);
+ return -ENOMEM;
+ }
p2m_initialise(d, p2m);
/* Must initialise nestedp2m unconditionally
@@ -333,6 +339,9 @@ static void p2m_teardown_nestedp2m(struc
uint8_t i;
for (i = 0; i < MAX_NESTEDP2M; i++) {
+ if ( !d->arch.nested_p2m[i] )
+ continue;
+ free_cpumask_var(d->arch.nested_p2m[i]->dirty_cpumask);
xfree(d->arch.nested_p2m[i]);
d->arch.nested_p2m[i] = NULL;
}
@@ -341,8 +350,12 @@ static void p2m_teardown_nestedp2m(struc
void p2m_final_teardown(struct domain *d)
{
/* Iterate over all p2m tables per domain */
- xfree(d->arch.p2m);
- d->arch.p2m = NULL;
+ if ( d->arch.p2m )
+ {
+ free_cpumask_var(d->arch.p2m->dirty_cpumask);
+ xfree(d->arch.p2m);
+ d->arch.p2m = NULL;
+ }
/* We must teardown unconditionally because
* we initialise them unconditionally.
@@ -1200,7 +1213,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
if (p2m->cr3 == CR3_EADDR)
hvm_asid_flush_vcpu(v);
p2m->cr3 = cr3;
- cpu_set(v->processor, p2m->p2m_dirty_cpumask);
+ cpumask_set_cpu(v->processor, p2m->dirty_cpumask);
p2m_unlock(p2m);
nestedp2m_unlock(d);
return p2m;
@@ -1217,7 +1230,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
p2m->cr3 = cr3;
nv->nv_flushp2m = 0;
hvm_asid_flush_vcpu(v);
- cpu_set(v->processor, p2m->p2m_dirty_cpumask);
+ cpumask_set_cpu(v->processor, p2m->dirty_cpumask);
p2m_unlock(p2m);
nestedp2m_unlock(d);
--- 2011-10-18.orig/xen/include/asm-x86/p2m.h 2011-10-21
09:24:51.000000000 +0200
+++ 2011-10-18/xen/include/asm-x86/p2m.h 2011-10-18 16:39:34.000000000
+0200
@@ -198,7 +198,7 @@ struct p2m_domain {
* this p2m and those physical cpus whose vcpu's are in
* guestmode.
*/
- cpumask_t p2m_dirty_cpumask;
+ cpumask_var_t dirty_cpumask;
struct domain *domain; /* back pointer to domain */
changeset: 23986:253073b522f8
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:23:05 2011 +0200
allocate CPU sibling and core maps dynamically
... thus reducing the per-CPU data area size back to one page even when
building for large NR_CPUS.
At once eliminate the old __cpu{mask,list}_scnprintf() helpers.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23985:eef4641d6726
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:22:02 2011 +0200
x86: allocate IRQ actions' cpu_eoi_map dynamically
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23984:07d303ff2757
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:21:09 2011 +0200
eliminate direct assignments of CPU masks
Use cpumask_copy() instead of direct variable assignments for copying
CPU masks. While direct assignments are not a problem when both sides
are variables actually defined as cpumask_t (except for possibly
copying *much* more than would actually need to be copied), they must
not happen when the original variable is of type cpumask_var_t (which
may have lass space allocated to it than a full cpumask_t). Eliminate
as many of such assignments as possible (in several cases it's even
possible to collapse two operations [copy then clear one bit] into one
[cpumask_andnot()]), and thus set the way for reducing the allocation
size in alloc_cpumask_var().
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23983:1a4223c62ee7
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:19:44 2011 +0200
eliminate cpumask accessors referencing NR_CPUS
... in favor of using the new, nr_cpumask_bits-based ones.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23982:511d5e65a302
user: Jan Beulich <jbeulich@xxxxxxxx>
date: Fri Oct 21 09:17:42 2011 +0200
introduce and use nr_cpu_ids and nr_cpumask_bits
The former is the runtime equivalent of NR_CPUS (and users of NR_CPUS,
where necessary, get adjusted accordingly), while the latter is for the
sole use of determining the allocation size when dynamically allocating
CPU masks (done later in this series).
Adjust accessors to use either of the two to bound their bitmap
operations - which one gets used depends on whether accessing the bits
in the gap between nr_cpu_ids and nr_cpumask_bits is benign but more
efficient.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
changeset: 23981:6c583d35d76d
user: Tim Deegan <tim@xxxxxxx>
date: Thu Oct 20 15:36:01 2011 +0100
x86/mm/p2m: don't leak state if nested-p2m init fails.
Signed-off-by: Tim Deegan <tim@xxxxxxx>
========================================
commit 25378e0a76b282127e9ab8933a4defbc91db3862
Author: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
Date: Thu Oct 6 18:38:08 2011 +0100
remove blktap when building for NetBSD
NetBSD has no blktap support, so remove the use of the blktap if the
OS is NetBSD.
Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home