> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, May 29, 2015 9:46 PM
>
> As suggested by Andrew Cooper, this patch attempts to remove
> some redundancy and allow for an easier time when adding vm_events
> for new control registers in the future, by having a single
> VM_E
Ping?
>>> On 15.05.15 at 14:41, wrote:
> Expecting the ROM BAR to be written with an all ones value when sizing
> the region is wrong - the low bit has another meaning (enable/disable)
> and bits 1..10 are reserved. The PCI spec also mandates writing all
> ones to just the address portion of the
Ping?
>>> On 15.05.15 at 14:46, wrote:
> The code introduced to address XSA-126 allows simplification of other
> code in xen_pt_initfn(): All we need to do is update "cmd" suitably,
> as it'll be written back to the host register near the end of the
> function anyway.
>
> Signed-off-by: Jan Beul
> From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com]
> Sent: Saturday, May 30, 2015 5:39 AM
>
> From: Elena Ufimtseva
>
> On some platforms RMRR regions may be not specified
> in ACPI and thus will not be mapped 1:1 in dom0. This
> causes IO Page Faults and prevents dom0 from b
From: Vaishali Thakkar
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:
>
> @change@
> expres
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
test-amd64-i386-xl-qemuu-win
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 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
>
> In preparation for auxiliary RMRR data provided on Xen
> command line, make RMRR adding a separate function.
> Also free memery for rmrr device scope in err
> 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
___
> From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com]
> Sent: Saturday, May 30, 2015 5:35 AM
>
> From: Elena Ufimtseva
>
> Release memory allocated for scope.devices when disabling
> dmar units. Also set device count after memory allocation when
> device scope parsing.
>
> Chan
From: Ian Campbell
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’
> [-Wformat=]
>
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
test-amd64-i386-xl-qem
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
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 wrote:
> >>
> >>Hi Chen,
> >>
> >>On 30/05/2015 12:07, Chen Baozi wrote:
> >>>From: Chen Baozi
> >>>
> >>>GIC-500 supports up to 128
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
On Sat, May 30, 2015 at 07:07:26PM +0800, Chen Baozi wrote:
> 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/
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
test-amd64-i386-x
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
>>> wrote:
+
#define NR_GIC_LOCAL_IRQS NR_LOCAL_IRQS
#define NR_GIC_SGI 16
#define MAX_RDIST_COUNT4
diff --git a/xen/
Hi Chen,
On 31/05/2015 16:37, Chen Baozi wrote:
On May 31, 2015, at 21:40, Julien Grall wrote:
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi
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?
Hi Chen,
On 31/05/2015 16:31, Chen Baozi wrote:
On May 31, 2015, at 21:35, Julien Grall 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 b/xen/include/asm-arm/vgic.h
index 2f413e1..1157b04
On 31/05/2015 16:25, Chen Baozi wrote:
On May 31, 2015, at 21:14, Julien Grall wrote:
On 30/05/2015 12:07, Chen Baozi wrote:
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/vg
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 f
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
Tests
> On May 31, 2015, at 21:40, Julien Grall wrote:
>
> Hi Chen,
>
> On 30/05/2015 12:07, Chen Baozi wrote:
>> From: Chen Baozi
>>
>> 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
> On May 31, 2015, at 21:35, Julien Grall wrote:
>
> Hi Chen,
>
> On 30/05/2015 12:07, Chen Baozi wrote:
>> 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_vc
Hi Julien,
> On May 31, 2015, at 21:14, Julien Grall wrote:
>
> Hi Chen,
>
> On 30/05/2015 12:07, Chen Baozi wrote:
>> 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
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
test-armhf-armhf-xl-m
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
From: Chen Baozi
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.
Regards,
--
Ju
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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 di
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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: Ch
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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
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
test-amd64-i386-fre
Hi Chen,
On 30/05/2015 12:07, Chen Baozi wrote:
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 o
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 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, 2015-05-06 at 18:47
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 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
test-amd64-i386-xl-qemuu-win
42 matches
Mail list logo
