flight 57597 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57597/
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
On May 31, 2015, at 21:35, Julien Grall julien.gr...@citrix.com wrote:
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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
flight 57600 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57600/
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
Hi Julien,
On May 31, 2015, at 21:14, Julien Grall julien.gr...@citrix.com wrote:
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by:
On May 31, 2015, at 21:40, Julien Grall julien.gr...@citrix.com wrote:
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Where did you find this restriction?
On 31/05/2015 16:25, Chen Baozi wrote:
On May 31, 2015, at 21:14, Julien Grall julien.gr...@citrix.com wrote:
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
On 31/05/15 19:05, Julien Grall wrote:
Hi Chen,
On 31/05/2015 16:31, Chen Baozi wrote:
On May 31, 2015, at 21:35, Julien Grall julien.gr...@citrix.com
wrote:
+
#define NR_GIC_LOCAL_IRQS NR_LOCAL_IRQS
#define NR_GIC_SGI 16
#define MAX_RDIST_COUNT4
diff --git
Hi Chen,
On 31/05/2015 16:37, Chen Baozi wrote:
On May 31, 2015, at 21:40, Julien Grall julien.gr...@citrix.com wrote:
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on
flight 57644 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57644/
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. 57419
build-armhf
flight 57645 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57645/
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. 57312
On Sat, May 30, 2015 at 07:07:26PM +0800, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by: Chen Baozi baoz...@gmail.com
---
xen/arch/arm/vgic-v3.c| 9
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
On Sun, May 31, 2015 at 07:21:22PM +0100, Julien Grall wrote:
Hi Chen,
On 31/05/2015 16:37, Chen Baozi wrote:
On May 31, 2015, at 21:40, Julien Grall julien.gr...@citrix.com wrote:
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
GIC-500 supports
flight 57630 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57630/
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
flight 57652 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57652/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854
test-amd64-amd64-libvirt
From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com]
Sent: Saturday, May 30, 2015 5:39 AM
From: Elena Ufimtseva elena.ufimts...@oracle.com
In preparation for auxiliary RMRR data provided on Xen
command line, make RMRR adding a separate function.
Also free memery for rmrr
From: Vaishali Thakkar vthakkar1...@gmail.com
Date: Mon, 1 Jun 2015 10:28:37 +0530
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
Hi Chen,
On 31/05/2015 16:31, Chen Baozi wrote:
On May 31, 2015, at 21:35, Julien Grall julien.gr...@citrix.com wrote:
+
#define NR_GIC_LOCAL_IRQS NR_LOCAL_IRQS
#define NR_GIC_SGI 16
#define MAX_RDIST_COUNT4
diff --git a/xen/include/asm-arm/vgic.h
From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com]
Sent: Saturday, May 30, 2015 5:35 AM
From: Elena Ufimtseva elena.ufimts...@oracle.com
Release memory allocated for scope.devices when disabling
dmar units. Also set device count after memory allocation when
device scope
From: Tian, Kevin
Sent: Monday, June 01, 2015 12:43 PM
and looks you dropped earlier changes to acpi_parse_one_rmrr. any
elaboration why it's not required in this version?
Thanks
Kevin
Never mind this one. Seems you have it in RMRR patch set.
Thanks
Kevin
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@change@
expression e, func, da;
@@
-init_timer (e);
+setup_timer (e, func, da);
-e.data =
flight 57649 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 29 May 2015 17:22:04 +0100
drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 5 has type ‘int’
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
flight 57573 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
flight 57580 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 3 host-install(3) broken REGR. vs. 53854
test-amd64-i386-libvirt
flight 57585 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
Thanks - let me know when it's created!
On 18 May 2015 at 13:54, Ian Jackson ian.jack...@eu.citrix.com wrote:
Birin, would you please create the list requested below ?
Thanks,
Ian.
Ian Campbell writes (Re: [Xen-devel] Mini-os mailing list):
(Sending this to IanJ's inbox)
On Wed,
flight 57591 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56831
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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.
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by: Chen Baozi baoz...@gmail.com
---
xen/arch/arm/vgic-v3.c| 9 -
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi baoz...@gmail.com
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Where did you find this restriction? AFAICT the changes you made in the
vGICv3 driver allow us to use up to 4096 CPUs.
flight 57594 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57594/
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
38 matches
Mail list logo
