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
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-
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
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
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-
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
_
[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
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
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
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-
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
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
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
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
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
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
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
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-
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
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
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
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
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
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
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
>>
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
26 matches
Mail list logo