flight 107454 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107454/
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
build-amd64-xsm
This run is configured for baseline tests only.
flight 71195 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71195/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-chec
flight 107456 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107456/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 6 xen-boot fail in 107448 pass in 107456
test-amd64-amd64-xl-qemuu-win
flight 107452 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
flight 107449 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107449/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 107406
test-amd64-i386-xl-q
On Fri, 14 Apr 2017, Stefano Stabellini wrote:
> Hi Paul,
>
> The following commit in my qemu "next" branch breaks the build on arm
> and arm64:
>
> commit 670271647ad15e9d937ced7a72c892349c709216
> Author: Paul Durrant
> Date: Tue Mar 7 10:55:34 2017 +
>
> xen: use libxendevicemodel
flight 107450 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107450/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176
Tests which are f
Hi Paul,
The following commit in my qemu "next" branch breaks the build on arm
and arm64:
commit 670271647ad15e9d937ced7a72c892349c709216
Author: Paul Durrant
Date: Tue Mar 7 10:55:34 2017 +
xen: use libxendevicemodel when available
See the appended build log. Sorry for not realizing
On Fri, Apr 14, 2017 at 06:53:36PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 19:20:08 +0200
> Daniel Kiper wrote:
> > On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> >[...]
> > > Tested-by: Petr Tesarik
> > >
> > > I copied the complete /proc/vmcore to a directory on disk.
flight 107448 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 107422
REGR. vs. 106822
On Fri, Apr 14, 2017 at 04:17:54PM +0100, Andrew Cooper wrote:
> On 14/04/2017 15:54, Daniel Kiper wrote:
> > Hey,
> >
> > Has anybody tried to run EFI + tboot + Xen?
> > I have a feeling that it does not work because
> > tboot shuts down EFI boot services. However,
> > even if it works then efiboo
On Fri, Apr 14, 2017 at 1:03 PM, Razvan Cojocaru
wrote:
> On 04/14/2017 09:08 PM, Tamas K Lengyel wrote:
> >
> >
> > On Thu, Apr 13, 2017 at 4:20 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
> > >
> > >
> >
This run is configured for baseline tests only.
flight 71194 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71194/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0c9fc4b1679946f59efa1aaf11e2e9e1acab303d
baseline v
On 04/14/2017 09:08 PM, Tamas K Lengyel wrote:
>
>
> On Thu, Apr 13, 2017 at 4:20 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
> >
> >
> > On Mon, Apr 10, 2017 at 3:44 AM, Razvan Cojocaru
> > +e
flight 107446 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107446/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107397
test-armhf-armhf-libvirt-xs
** Delivery incomplete **
There was a temporary problem delivering your message to
curtiskwo...@gmail.com. Gmail will retry for 21 more hours. You'll be notified
if the delivery fails permanently.
The response was:
Receive rate too high
Reporting-MTA: dns; googlemail.com
Received-From-MTA:
On Fri, Mar 31, 2017 at 10:32:09AM +0200, Dario Faggioli wrote:
> On Fri, 2017-03-31 at 00:58 +0530, Praveen Kumar wrote:
> > The patch introduces a new command line option 'custom' that when
> used will
> > create runqueue based upon the pCPU subset provide during bootup.
> >
> "introduces a new
On Thu, Apr 13, 2017 at 4:20 AM, Razvan Cojocaru
wrote:
> On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
> >
> >
> > On Mon, Apr 10, 2017 at 3:44 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > This patch adds support for testing instruction emulation when
> > re
On Fri, 14 Apr 2017, Juergen Gross wrote:
> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> > On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> >> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko
> >>>
> >>> For some use cases when Xen framebuffer/input
flight 107444 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107444/
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
build-amd64-xsm
On Tue, 11 Apr 2017 19:20:08 +0200
Daniel Kiper wrote:
> On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
>[...]
> > Tested-by: Petr Tesarik
> >
> > I copied the complete /proc/vmcore to a directory on disk. Exactly
> > as expected, crash works both without the patch and with the pa
** Delivery incomplete **
There was a temporary problem delivering your message to
curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified
if the delivery fails permanently.
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2Y
flight 107447 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107447/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0c9fc4b1679946f59efa1aaf11e2e9e1acab303d
baseline version:
ovmf e06179889586c37101e29
** Delivery incomplete **
There was a temporary problem delivering your message to
curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified
if the delivery fails permanently.
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2Y
Hi Paul:
Sorry for later response.
On 3/31/2017 3:57 AM, Chao Gao wrote:
On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
Chao Gao
Sent: 29 March 2017 01:40
To: Wei Liu
Cc: Lan
This is needed for subsequent changes to memory scrubbing.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Simplify merge_and_free_buddy() (and drop can_merge())
xen/common/page_alloc.c | 74 ++-
1 files changed, 41 insertions(+), 33 deletions(
Signed-off-by: Boris Ostrovsky
Reviewed-by: Wei Liu
---
xen/common/page_alloc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 514a4a1..dd6f248 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc
When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.
Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_page
While scrubbing from idle loop, check for softirqs every 256 pages.
If softirq is pending, don't scrub any further and merge the
partially-scrubbed buddy back into heap by breaking the clean portion
into smaller power-of-2 chunks. Then repeat the same process for the
dirty part.
Signed-off-by: Bor
While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.
Specifically, this feature will be needed by scrubbing code where
the scrubber,
When a domain is destroyed the hypervisor must scrub domain's pages before
giving them to another guest in order to prevent leaking the deceased
guest's data. Currently this is done during guest's destruction, possibly
causing very lengthy cleanup process.
This series adds support for scrubbing re
Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.
Signed-off-by: Boris Ostrovsky
---
xen/Kconfig.debug |7 ++
xen/common/page_alloc.c | 49 ++-
2 files chan
. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Keep dirty bit per page, add dirty_head to page_info that indicates whether
the buddy has dirty pages.
* Make page_list_add_scrub
Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's PAGE_SCRUB_ABORT bit. The scrubber checks
Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* If memory-only nodes exist, select the closest one for scrubbing
* Don't scrub from idle loop until we reach SYS_STATE_ac
Hello,
Although PVHv2 Dom0 is not yet finished, I've been trying the current code on
different hardware, and found that with pre-Haswell Intel hardware PVHv2 Dom0
completely freezes the box when calling iommu_hwdom_init in dom0_construct_pvh.
OTOH the same doesn't happen when using a newer CPU (ie
On Fri, Apr 14, 2017 at 05:03:41PM +0200, Florian Heigl wrote:
> Hi everyone!
>
> last month I hit a weird bug with PV-Grub in AlpineLinux 3.5
> Basically, after updating PV-Grub you can no longer boot your VMs unless
> they’re on an ext2 partition.
> This also happened to others and apparently a
On 14/04/2017 15:54, Daniel Kiper wrote:
> Hey,
>
> Has anybody tried to run EFI + tboot + Xen?
> I have a feeling that it does not work because
> tboot shuts down EFI boot services. However,
> even if it works then efibootmgr is unusable
> due to lack of EFI runtime services. Do we care?
> Is it p
Hi everyone!
last month I hit a weird bug with PV-Grub in AlpineLinux 3.5
Basically, after updating PV-Grub you can no longer boot your VMs unless
they’re on an ext2 partition.
This also happened to others and apparently also on Gentoo.
Natanael Copa has been kind enough to dig in, but it’s gott
flight 107443 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
Hey,
Has anybody tried to run EFI + tboot + Xen?
I have a feeling that it does not work because
tboot shuts down EFI boot services. However,
even if it works then efibootmgr is unusable
due to lack of EFI runtime services. Do we care?
Is it possible to make it work with full blown
EFI infrastructu
On 04/14/2017 05:17 AM, Greg KH wrote:
> On Thu, Apr 13, 2017 at 03:06:53PM +0200, Juergen Gross wrote:
>> Revert commit 72a9b186292 ("xen: Remove event channel notification
>> through Xen PCI platform device") as the original analysis was wrong
>> that all the removed code isn't in use any more.
>
flight 107441 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176
Tests which are f
On Thu, Apr 13, 2017 at 09:44:17PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 13, 2017 at 04:11:25PM +0200, Daniel Kiper wrote:
> > On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote:
> > > >>> On 21.02.17 at 20:19, wrote:
> > > > Every multiboot protocol (regardless of version) co
This run is configured for baseline tests only.
flight 71193 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71193/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e06179889586c37101e2900e7f52be9f0da12cda
baseline v
On Thu, Apr 13, 2017 at 02:43:22PM -0500, Doug Goldstein wrote:
> On 4/13/17 9:11 AM, Daniel Kiper wrote:
> > On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote:
> > On 21.02.17 at 20:19, wrote:
> >>> Every multiboot protocol (regardless of version) compatible image must
> >>> specify
They aren't limited to proc file system anymore. Use more generic names.
No functional change.
Signed-off-by: Wei Liu
---
This is a follow-up patch for "oxenstored: make it work on FreeBSD".
Cc: Ian Jackson
Cc: d...@recoil.org
Cc: christian.lin...@citrix.com
Cc: jonathan.lud...@citrix.com
Cc:
I managed to remove almost all Linux-ism in my previous work to make all paths
configurable.
The last bits missing are the two device node paths.
Unfortunately there is an easy way to determine system name in the standard
library so I wrote a wrapper for uname syscall.
I think this is a good can
Call the uname syscall to determine sysname and return device names
accordingly.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: d...@recoil.org
Cc: christian.lin...@citrix.com
Cc: jonathan.lud...@citrix.com
Cc: Roger Pau Monné
---
tools/ocaml/xenstored/define.ml | 16 ++--
1 file c
Currently there is only uname syscall in it.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: d...@recoil.org
Cc: christian.lin...@citrix.com
Cc: jonathan.lud...@citrix.com
Cc: Roger Pau Monné
---
tools/ocaml/xenstored/Makefile | 9 --
tools/ocaml/xenstored/unix_syscalls.ml
On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV
> display device driver interface"):
>> After internal discussion we think that putting positions and
>> z-orders of virtual connectors to the Xen store and libxl
>> confi
flight 107442 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107442/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107417
test-armhf-armhf-libvirt-raw 12
flight 71192 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71192/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
On Thu, Apr 13, 2017 at 03:06:53PM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more.
>
> It is still necessary for old Xen versio
flight 107439 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 107422
REGR. vs. 106822
On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> For some use cases when Xen framebuffer/input backend
>>> is not a part of Qemu it is required to d
flight 107440 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107440/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e06179889586c37101e2900e7f52be9f0da12cda
baseline version:
ovmf d63ed30bb508f46ec304c
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Monday, February 6, 2017 7:33 PM
>
> On Fri, 2017-01-27 at 10:36 -0500, Konrad Rzeszutek Wilk wrote:
> > . snip ..
> > >
> > > >
> > > > Signed-off-by: David Woodhouse
> > > Reviewed-by: Jan Beulich
> > >
> > > But before committing I'
flight 107438 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-bootfail REGR. vs. 107397
Regressions which
Hi Stefano,
On 12 April 2017 at 03:37, Stefano Stabellini wrote:
> On Tue, 11 Apr 2017, Bhupinder Thakur wrote:
>> Hi,
>>
>> Kindly let me know if my understanding is correct.
>>
>> Using a domctl API will allow us to keep the vUART configuration
>> flexible. Currently, we can operate on one ring
60 matches
Mail list logo
