flight 57642 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
flight 57568 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57568/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 57312
Tests which are failin
flight 57567 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 57419
test-amd64-i386-free
flight 57553 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57553/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-winxpsp3 16 guest-stop fail REGR. vs. 53018
test-amd64-i386-x
On 30/05/2015 23:07, M A Young wrote:
> On Fri, 29 May 2015, Andrew Cooper wrote:
>
>> On 29/05/15 12:17, M A Young wrote:
> I did a bit of testing - xen-4.5.1-rc1 built on Fedora 22 (gcc5) doesn't
> boot for me, but if I replace xen.gz with one from the same code built on
> Fedora 21
On Fri, 29 May 2015, Andrew Cooper wrote:
> On 29/05/15 12:17, M A Young wrote:
> >
> >>> I did a bit of testing - xen-4.5.1-rc1 built on Fedora 22 (gcc5) doesn't
> >>> boot for me, but if I replace xen.gz with one from the same code built on
> >>> Fedora 21 (gcc4) then it does boot. There are r
On 05/27/2015 12:47 PM, Lars Kurth wrote:
> ...
> 4. Advisory pre-release:
>
> This occurs only if the advisory is embargoed (ie, the problem is not already
> public):
>
> As soon as our advisory is available, we will send it, including patches, to
> members of the Xen security pre-disclosure
flight 37597 linux-next real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37597/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels
fail like 36777
test-amd64-i
On 30/05/15 16:39, Mikko Rapeli wrote:
> privcmd.h depends on xen/interface/xen.h which is now exported to userspace.
> xen/interface/xen.h then depends on asm/xen/interface.h which is now
> exported to userspace together with its dependencies asm/xen/interface_32.h,
> asm/xen/interface_64.h and as
privcmd.h depends on xen/interface/xen.h which is now exported to userspace.
xen/interface/xen.h then depends on asm/xen/interface.h which is now
exported to userspace together with its dependencies asm/xen/interface_32.h,
asm/xen/interface_64.h and asm/pvclock-abi.h on x86 architecture.
Then all
Fixes userspace compilation errors like:
xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/xen/gntalloc.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/x
Fixes userspace compilation errors like:
xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/xen/gntdev.h | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/include/uapi/xen/gntdev.h b/include/
flight 57532 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57532/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 57442
Regressions which are
On Thu, 28 May 2015 21:18:44 +0200
"Luis R. Rodriguez" wrote:
> > As a nit, I would take out "have a preference to".
>
> Fine by me, do you need a new submission on my part of can you amend yourself?
I can tweak it on the way in.
Thanks,
jon
___
On Thu, 28 May 2015 11:56:01 -0700
"Luis R. Rodriguez" wrote:
> +Some maintainers and developers may however have a preference to
> +require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality.
As a nit, I would take out "have a preference to".
>From what I can tell, there are
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 37590 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37590/
Regressions :-
On Thu, May 28, 2015 at 12:58 AM, Bjorn Helgaas wrote:
> On Tue, May 26, 2015 at 04:17:05AM +0200, Rafael J. Wysocki wrote:
>> On Tuesday, May 26, 2015 03:08:17 AM Rafael J. Wysocki wrote:
>> > On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote:
>> > > On Tuesday, May 26, 2015 01:22:12 A
API consolidation with coccinelle found:
./arch/x86/xen/smp.c:499:2-18:
consolidation with schedule_timeout_*() recommended
This is a 1:1 conversion of the current calls to an available helper
only - so only an API consolidation to improve readability.
Patch was compile tested with x86_6
On Tue, May 19, 2015 at 12:47:51PM +0100, Ian Campbell wrote:
The reconcatenate bit is easy, just:
$ cat initrd.ucode initrd.real > initrd.img
With initrd.real extracted above.
initrd.ucode creation I'm a little unsure about but something like:
$ mkdir initrd.ucode.tree
$ cd initrd.ucode.tree
Hi,
I am running kernel 3.11-rc3 on arndale exynos 5250 board with xen 4.5
stack. It works fine with domU with kernel 3.17+ with ubutnu.
I am trying to run android as domU, so I am using kernel 3.9 in domU. With
kernel 3.9 in domU, xen doesn't even boot the kernel at all. Here is the
strace log ht
flight 57528 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57528/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 16 guest-stop fail REGR. vs. 53768
Tests which are f
flight 57522 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 56941
test-
From: Chen Baozi
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Since the domain_max_vcpus has been changed to depends on vgic_ops,
we could have done more work in order to drop the definition of
MAX_VIRT_CPUS. However, because it is still used for some
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
xen/arch/arm/domain_build
From: Chen Baozi
evtchn_init() will call domain_max_vcpus() to allocate poll_mask, which
needs the max vCPU number returned by domain_max_vcpus(). On arm/arm64
platform, this number is determined by the vGIC the guest is going to
use, which won't be initialised until arch_domain_create() is finis
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which is 128 at the moment.
So the domain_max_vcpus should return the value according to the vGIC
the domain uses.
We didn't keep it as the old static inline form because
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c|
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_arm.c |
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c| 9 -
xen/include/asm-arm/gic_v3_defs.h | 3 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Also make the code for PSC
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC-
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC-
Control: fixed -1 4.0-1~exp1
On Wed, 2015-03-04 at 11:14 +, David Vrabel wrote:
> Use correct pointer arithmetic to get the pointer to each stat.
I think this incorrect arithmetic was also responsible for the crash
reported in http://bugs.debian.org/786936 which was using the resulting
stray
flight 57516 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 3 host-install(3) broken REGR. vs. 57442
test-amd64-amd64-rump
flight 57513 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 56831
Regressions which
flight 57581 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57581/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
39 matches
Mail list logo
