This run is configured for baseline tests only.
flight 71428 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71428/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 109737 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109737/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 687bde9cac2ce1a45d916bc26caa370d15d58fce
baseline version:
ovmf 0fff7d6740419417b6536
flight 109717 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109717/
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. 107358
Tests which are faili
flight 109716 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 109697
test-amd64-i386-libv
This run is configured for baseline tests only.
flight 71427 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-
flight 109731 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109731/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0fff7d6740419417b65361529612a49a6a2b96b2
baseline version:
ovmf a0284a9a5820e470bae25
flight 109727 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109727/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 109720
version targeted for test
Hi Dave,
On 05/24/2017 11:56 PM, Dave Anderson wrote:
Queued for crash-7.2.0:
https://github.com/crash-utility/crash/commit/5c52842a58a2602dba81de71831af98b2b53c6e0
Thanks,
Dave
It's great! Thanks a lot.
Honglei
___
Xen-devel mailing list
flight 109711 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109711/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 109701 pass
in 109711
test-amd64-i386-xl-qem
George,
The live migrate pass over 500+ times with this patch, I think it's fine to
merge it into Xen 4.9.
Tested-by: Xudong Hao
Thanks,
-Xudong
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Hao,
> Xudong
> Sent: Tuesday, May 23, 2017 5
This run is configured for baseline tests only.
flight 71426 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71426/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
On Wed, 24 May 2017, Andrew Cooper wrote:
On 24/05/17 17:14, Ian Jackson wrote:
CC: Julien Grall
CC: M A Young
CC: Andrew Cooper
CC: Wei Liu
Signed-off-by: Ian Jackson
This resolves all the XenServer build issues I encountered.
Tested-by: Andrew Cooper
I tried building with both patc
flight 109720 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109720/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a0284a9a5820e470bae2557a7e25c426e62c8a4e
baseline version:
ovmf d727614c913449a59e833
flight 109709 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109709/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 109692
test-armhf-armhf-libvirt 13 saveresto
flight 109707 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109707/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3)broken REGR. vs. 10969
flight 109725 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109725/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Wed, 24 May 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 05/23/2017 07:23 PM, Stefano Stabellini wrote:
> > On Tue, 23 May 2017, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 23/05/17 00:48, Stefano Stabellini wrote:
> > > > On Fri, 19 May 2017, Stefano Stabellini wrote:
> > > > > On
On 24/05/17 17:14, Ian Jackson wrote:
> CC: Julien Grall
> CC: M A Young
> CC: Andrew Cooper
> CC: Wei Liu
> Signed-off-by: Ian Jackson
This resolves all the XenServer build issues I encountered.
Tested-by: Andrew Cooper
___
Xen-devel mailing lis
On 05/24/2017 06:21 AM, Jan Beulich wrote:
On 24.05.17 at 11:14, wrote:
>> Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
>> pages") left the NPT code untouched, as there is no explicit alignment
>> check matching the one in EPT code. However, the now more widespread
>> st
On 24/05/17 17:40, Boris Ostrovsky wrote:
> On 05/19/2017 11:47 AM, Juergen Gross wrote:
>> Add a new config item PARAVIRT_FULL. It will be used to guard the
>> pv_*_ops functions used by fully paravirtualized guests (Xen pv-guests
>> and lguest) only.
>>
>> Kernels not meant to support those guest
Recent changes to this Makefile have broken some build targets, and
some parallel builds.
Looking at it, I think I have identified the undocumented design
intent in the top-level Makefile. So in this patch I document it, and
also make it true.
In detail:
* Add a comment with the new design int
This is the only one of the Makefiles invoked with -C from the
toplevel which lacks this target.
CC: Julien Grall
CC: M A Young
CC: Andrew Cooper
CC: Wei Liu
Signed-off-by: Ian Jackson
---
tools/include/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/in
I'm about to post a pair of patches, against staging, which I think
fix this problem.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
- Original Message -
> crash patch c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add support for
> dom0 with Linux kernel 3.19 and newer) from Daniel made crash utility
> support xen dom0 vmcores after linux kernel commit
> 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
>>> On 24.05.17 at 17:00, wrote:
> On 5/24/2017 1:43 AM, Jan Beulich wrote:
> On 23.05.17 at 23:51, wrote:
>>> On 5/23/2017 4:46 PM, Boris Ostrovsky wrote:
On 05/23/2017 05:28 PM, Gary R Hook wrote:
> Signed-off-by: Gary R Hook
> ---
>xen/arch/x86/oprofile/nmi_int.c |
flight 109706 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 7 host-ping-check-xen fail REGR. vs. 109656
test-amd64-amd64-li
Am Wed, 24 May 2017 11:33:15 -0400
schrieb Konrad Rzeszutek Wilk :
> But it does not help customers to figure out if this is OK for them?
> As in, how can customers be assured that 1% jitter is OK for their
> kernel? That time won't go backwards?
Well, that would be some new documentation.
I thin
On 05/19/2017 11:47 AM, Juergen Gross wrote:
> Add a new config item PARAVIRT_FULL. It will be used to guard the
> pv_*_ops functions used by fully paravirtualized guests (Xen pv-guests
> and lguest) only.
>
> Kernels not meant to support those guest types will be able to use many
> operations with
Wei Liu writes ("Re: [PATCH for-4.9] tools/build: Fix installation of public
headers"):
> Reviewed-by: Wei Liu
FAOD I think this patch is broken and am developing a replacement.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xe
On Wed, May 24, 2017 at 05:25:03PM +0200, Olaf Hering wrote:
> On Wed, May 24, Konrad Rzeszutek Wilk wrote:
>
> > How can that be determined? As in how can the guest (domU) be within
> > the range? Is there some way to determine that? Is there some
> > matrix of the various OS-es that can tolerate
On Wed, May 24, Konrad Rzeszutek Wilk wrote:
> How can that be determined? As in how can the guest (domU) be within
> the range? Is there some way to determine that? Is there some
> matrix of the various OS-es that can tolerate this?
Just cycle through all dom0s and look for the cpu_khz values:
On Wed, May 24, 2017 at 04:25:05PM +0200, Olaf Hering wrote:
> After migrating a domU to another identical host a performance drop can
> be observed. One reason is that before migration TSC was accessed at
> native speed, after migration TSC has to be emulated. This happens
> because the measured C
On 5/24/2017 1:43 AM, Jan Beulich wrote:
On 23.05.17 at 23:51, wrote:
On 5/23/2017 4:46 PM, Boris Ostrovsky wrote:
On 05/23/2017 05:28 PM, Gary R Hook wrote:
Signed-off-by: Gary R Hook
---
xen/arch/x86/oprofile/nmi_int.c |4
1 file changed, 4 insertions(+)
diff --git a/xen/arc
On Mon, May 22, 2017 at 06:00:49PM +0100, Andrew Cooper wrote:
> The recent build fixes have left the install-tools rule no longer installing
> the Xen public headers into /usr/include/xen/
>
> Use pattern rules to generalise the %-tools-public-headers targets, and switch
> install-tools to depend
After migrating a domU to another identical host a performance drop can
be observed. One reason is that before migration TSC was accessed at
native speed, after migration TSC has to be emulated. This happens
because the measured CPU frequency is not accurate, the values differ
even between reboots.
On 23/05/17 16:14, Jan Beulich wrote:
On 23.05.17 at 16:12, wrote:
>> The condition: if there is a space in the ring then wait for the producer
>> to fill the ring also evaluates to true even if the ring if full. It
>> leads to a deadlock where producer is waiting for consumer
>> to consume t
On Tue, May 23, 2017 at 06:58:59PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 5/7] osstest: introduce a FreeBSD build
> script"):
> > -my $path= "path_${part}dist";
> > -logm("checking $k $path");
> > -get_stashed($path, $r{$k});
> > +if ("$part" eq "freebsd") {
>
This run is configured for baseline tests only.
flight 71420 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71420/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
Roger Pau Monne writes ("Re: [PATCH 5/7] osstest: introduce a FreeBSD build
script"):
> On Tue, May 23, 2017 at 06:58:59PM +0100, Ian Jackson wrote:
> > Suppose we have ts-freebsd-build set
> > path_freebsddist=$stash/build/freebsd/
> > and have it put the files in there with fixed, known, nam
Hi,
On 24/05/17 10:56, Julien Grall wrote:
> Hi Andre,
>
> On 05/24/2017 10:10 AM, Andre Przywara wrote:
>> On 17/05/17 19:07, Julien Grall wrote:
/*
* Lookup the address of the Interrupt Translation Table associated
with
* that device ID.
@@ -414,6 +429,133 @@ out_u
flight 109714 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109714/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d727614c913449a59e8333c4d75cff4ebf1f9779
baseline version:
ovmf 1c47fcd465a496fe1d149
flight 71418 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71418/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
71334
test-amd64-i
Roger Pau Monne writes ("Re: [PATCH 4/7] osstest: add a FreeBSD host install
recipe"):
> OK, so then I will just drop FreeBSDBase and just use
> $ho->{Tftp}{TmpDir}/freebsd-images. I don't think there's a lot of
> value in have it in a standard folder, since those are just random
> builds. I guess
Olaf Hering writes ("[PATCH] docs: replace xm with xl in xen-tscmode"):
> Signed-off-by: Olaf Hering
Olaf Hering writes ("[PATCH] docs: correct paragraph indention in xen-tscmode"):
> Signed-off-by: Olaf Hering
Both:
Acked-by: Ian Jackson
I think these good for 4.9 and are covered by Julien'
On Tue, May 23, 2017 at 05:04:10PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 4/7] osstest: add a FreeBSD host install
> recipe"):
> > The installation is performed using the bsdinstall tool, which is
> > part of the FreeBSD base system. The installer image is setup with
> > the o
Stefano Stabellini writes:
> On Mon, 15 May 2017, Punit Agrawal wrote:
>> populate_physmap() calls alloc_heap_pages() per requested
>> extent. alloc_heap_pages() invalidates the entire icache per
>> extent. During domain creation, the icache invalidations can be deffered
>> until all the extents
>>> On 24.05.17 at 11:14, wrote:
> Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
> pages") left the NPT code untouched, as there is no explicit alignment
> check matching the one in EPT code. However, the now more widespread
> storing of INVALID_MFN into PTEs requires adjustme
Hi Stefano,
On 05/23/2017 06:47 PM, Stefano Stabellini wrote:
On Tue, 23 May 2017, Julien Grall wrote:
Hi Stefano,
On 22/05/17 23:19, Stefano Stabellini wrote:
On Tue, 16 May 2017, Julien Grall wrote:
@@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct
vcpu
*v, mmio_info_t
Hi Andre,
On 05/24/2017 10:10 AM, Andre Przywara wrote:
On 17/05/17 19:07, Julien Grall wrote:
/*
* Lookup the address of the Interrupt Translation Table associated with
* that device ID.
@@ -414,6 +429,133 @@ out_unlock:
return ret;
}
+/* Must be called with the ITS lock held. */
+
Hi Stefano,
On 05/23/2017 07:23 PM, Stefano Stabellini wrote:
On Tue, 23 May 2017, Julien Grall wrote:
Hi Stefano,
On 23/05/17 00:48, Stefano Stabellini wrote:
On Fri, 19 May 2017, Stefano Stabellini wrote:
On Thu, 11 May 2017, Andre Przywara wrote:
When LPIs get unmapped by a guest, they m
flight 109703 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109703/
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. 107358
test-amd64-amd64-xl-q
Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
pages") left the NPT code untouched, as there is no explicit alignment
check matching the one in EPT code. However, the now more widespread
storing of INVALID_MFN into PTEs requires adjustments:
- calculations when shattering large
Signed-off-by: Olaf Hering
---
docs/man/xen-tscmode.pod.7 | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7
index 0f9345358d..4e1858556c 100644
--- a/docs/man/xen-tscmode.pod.7
+++ b/docs/man/xen-tscmode.pod.7
@@ -96,1
Signed-off-by: Olaf Hering
---
docs/man/xen-tscmode.pod.7 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7
index 4e1858556c..3bbc96f201 100644
--- a/docs/man/xen-tscmode.pod.7
+++ b/docs/man/xen-tscmode.pod.7
@@ -105,1
Hi,
On 17/05/17 19:07, Julien Grall wrote:
> Hi Andre,
>
> On 11/05/17 18:53, Andre Przywara wrote:
>> The MAPD command maps a device by associating a memory region for
>> storing ITEs with a certain device ID. Since it features a valid bit,
>> MAPD also covers the "unmap" functionality, which we
On 05/23/2017 06:24 PM, Andre Przywara wrote:
Hi,
Hi Andre,
On 17/05/17 18:45, Julien Grall wrote:
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected,
On Tue, May 23, 2017 at 04:01:33PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 3/7] osstest: fix regular expression used to
> match buildjob in ts-build-check"):
> > Current regular expression used to match the buildjob works correctly when
> > the
> > buildjob runvar has the buil
crash patch c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add support for
dom0 with Linux kernel 3.19 and newer) from Daniel made crash utility
support xen dom0 vmcores after linux kernel commit
054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear virtual
mapped sparse p2m list).
This
On 24/05/17 02:34, Bart Van Assche wrote:
> Since the SCSI core zeroes driver-private command data, remove
> that code from the xen-scsifront driver.
>
> Signed-off-by: Bart Van Assche
> Cc: Juergen Gross
> Cc: xen-de...@lists.xenproject.org
Reviewed-by: Juergen Gross
Thanks,
Juergen
__
59 matches
Mail list logo
