[Xen-devel] [linux-4.1 test] 97434: regressions - FAIL

2016-07-17 Thread osstest service owner
flight 97434 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/97434/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR. vs. 96211 test-amd64-i386-xl-qemu

[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-xl-qemuu-winxpsp3

2016-07-17 Thread osstest service owner
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-winxpsp3 testid windows-install Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-

[Xen-devel] [xen-unstable-coverity test] 97501: regressions - ALL FAIL

2016-07-17 Thread osstest service owner
flight 97501 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/97501/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd645 coverity-buildfail REGR. vs. 96924 version tar

[Xen-devel] [qemu-mainline test] 97470: regressions - FAIL

2016-07-17 Thread osstest service owner
flight 97470 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/97470/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 96791 test-amd64-amd64-li

[Xen-devel] [ovmf test] 97478: regressions - FAIL

2016-07-17 Thread osstest service owner
flight 97478 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/97478/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 test-amd64-amd64-

Re: [Xen-devel] [v9 00/19] QEMU:Xen stubdom vTPM for HVM virtual machine(QEMU Part)

2016-07-17 Thread Quan Xu
On 2016 Jul 14 (Thu) 23:34, Stefano Stabellini  wrote:> Hi Quan, >  > thanks for CC'ing me. sstabell...@kernel.org is the right address to > reach me now. > > I am also CC'ing Anthony Perard who is Xen co-maintainer in QEMU. >  > Cheers, > > Stefano thanks in advance!! :):)Quan _

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

2016-07-17 Thread Quan Xu
[Quan:]: comment starts with [Quan:] The purpose of the new file is to store generic functions shared by frontendand  backends such as xenstore operations, xendevs. Signed-off-by: Quan Xu  Signed-off-by: Emil Condrea  ---  hw/xen/Makefile.objs |   2 +-  hw/xen/xen_backend.c | 12

[Xen-devel] [xen-unstable test] 97477: tolerable FAIL

2016-07-17 Thread osstest service owner
flight 97477 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/97477/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 6 xen-bootfail pass in 97410 test-amd64-i386-qemuu-rhel6hvm-int

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

2016-07-17 Thread Emil Condrea
On Jul 17, 2016 10:41, "Quan Xu" wrote: > > > [Quan:]: comment starts with [Quan:] > Thanks, Quan for your comments. The first patches from this series just move some code from xen_backend to xen_pvdev file. I would not group the reorg from xen_backend with refactoring in the same patch. Eventual

[Xen-devel] [linux-3.18 test] 97487: regressions - trouble: blocked/broken/fail/pass

2016-07-17 Thread osstest service owner
flight 97487 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/97487/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 96188 test-amd64-amd64-

[Xen-devel] [PATCH V2 2/4] xen: Add generic implementation of binary search

2016-07-17 Thread Shanker Donthineni
This patch adds the generic implementation of binary search algorithm whcih is copied from Linux kernel v4.7-rc7. No functional changes. Signed-off-by: Shanker Donthineni Reviewed-by: Andrew Cooper --- Changes since v1: Removed the header file xen/include/xen/bsearch.h. Defined function bsearc

[Xen-devel] [PATCH V2 0/4] Change fixed mmio handlers to a variable number

2016-07-17 Thread Shanker Donthineni
The maximum number of mmio handlers that are allowed is limited to a macro MAX_IO_HANDLER(16), which is not enough for supporting per CPU Redistributor regions. We need at least MAX_IO_HANDLER+CONFIG_NR_CPUS mmio handlers in order to support ACPI based XEN boot. This patchset uses the dynamic allo

[Xen-devel] [PATCH V2 4/4] arm/vgic: Change fixed number of mmio handlers to variable number

2016-07-17 Thread Shanker Donthineni
Compute the number of mmio handlers that are required for vGICv3 and vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment this variable number of mmio handers to a fixed number MAX_IO_HANDLER and pass it to domain_io_init() to allocate enough memory. New code path: domain_vgic_regis

[Xen-devel] [PATCH V2 3/4] xen/arm: io: Use binary search for mmio handler lookup

2016-07-17 Thread Shanker Donthineni
As the number of I/O handlers increase, the overhead associated with linear lookup also increases. The system might have maximum of 144 (assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario, it would require 144 iterations for finding a matching handler. Now it is time for us to chang

[Xen-devel] [PATCH V2 1/4] arm/io: Use separate memory allocation for mmio handlers

2016-07-17 Thread Shanker Donthineni
The number of mmio handlers are limited to a compile time macro MAX_IO_HANDLER which is 16. This number is not at all sufficient to support per CPU distributor regions. Either it needs to be increased to a bigger number, at least CONFIG_NR_CPUS+16, or allocate a separate memory for mmio handlers dy

[Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

2016-07-17 Thread Haozhong Zhang
Hi, Following is version 2 of the design doc for supporting vNVDIMM in Xen. It's basically the summary of discussion on previous v1 design (https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg6.html). Any comments are welcome. The corresponding patches are WIP. Thanks, Haozhong

[Xen-devel] [linux-4.1 test] 97496: regressions - FAIL

2016-07-17 Thread osstest service owner
flight 97496 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/97496/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 96211 test-a

[Xen-devel] [ovmf test] 97509: regressions - FAIL

2016-07-17 Thread osstest service owner
flight 97509 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/97509/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 test-amd64-amd64-

[Xen-devel] [qemu-mainline test] 97504: regressions - trouble: blocked/broken/fail/pass

2016-07-17 Thread osstest service owner
flight 97504 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/97504/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3 host-install(3) broken REGR. vs. 96791 test-amd64-amd64-li

[Xen-devel] (no subject)

2016-07-17 Thread 姚 忠将
Recently , I made a test to compare the performance of I/O between xen project and xenserver. I found the performance of xenserver is much better than that of xen project . I want to find the reason why xenserver is better so I search through google.com. On the website www.xenproject.org

Re: [Xen-devel] [PATCH 1/3] xen-scsiback: Delete an unnecessary check before the function call "kfree"

2016-07-17 Thread Juergen Gross
On 16/07/16 22:22, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 16 Jul 2016 21:21:05 +0200 > > The kfree() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle

Re: [Xen-devel] [PATCH 3/3] xen-scsiback: Pass a failure indication as a constant

2016-07-17 Thread Juergen Gross
On 16/07/16 22:24, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 16 Jul 2016 21:55:01 +0200 > > Pass the constant "FAILED" in a function call directly instead of > using an intialisation for a local variable. > > Signed-off-by: Markus Elfring Reviewed-by: Juergen Gross Juerge

Re: [Xen-devel] [PATCH 2/3] xen-scsiback: One function call less in scsiback_device_action() after error detection

2016-07-17 Thread Juergen Gross
On 16/07/16 22:23, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 16 Jul 2016 21:42:42 +0200 > > The kfree() function was called in one case by the > scsiback_device_action() function during error handling > even if the passed variable "tmr" contained a null pointer. > > Adjust jum

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

2016-07-17 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/arm/xen/enlighten.c between commit: 4761adb6f490 ("arm/xen: Convert to hotplug state machine") from the tip tree and commit: ecb23dc6f2ef ("xen: add steal_clock support on x86") from the xen-tip tree. I fixed

Re: [Xen-devel] [PATCH 1/2] xenstore: call each xenstored command function with temporary context

2016-07-17 Thread Juergen Gross
On 15/07/16 18:19, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 1/2] xenstore: call each xenstored command > function with temporary context"): >> In order to be able to avoid leaving temporary memory allocated after >> processing of a command in xenstored call all command functions with >>

Re: [Xen-devel] [PATCH 2/2] xenstore: use temporary memory context for firing watches

2016-07-17 Thread Juergen Gross
On 15/07/16 18:21, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 2/2] xenstore: use temporary memory context for > firing watches"): >> Use a temporary memory context for memory allocations when firing >> watches. This will avoid leaking memory in case of long living >> connections and/or xen