flight 116173 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 116126
test-armhf-armhf-
Hello Andrii,
>> BTW, what is your dom0 system? Does it have bash?
> *dom0 uses a modified kernel(3.15) with Xen support and default omap fs*
I made certain changes to my configuration file. Instead of trying to use a
disk, I want to the guest domain up from ramdisk image. My new
configuration
flight 116168 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116168/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are failing
On 15 November 2017 at 02:16, Oleksandr Tyshchenko wrote:
> On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara
> wrote:
>
> 3. Direct ported SCPI protocol, mailbox infrastructure and the ARM SMC
> triggered mailbox driver. All components except mailbox driver are in
> mainline Linux.
This run is configured for baseline tests only.
flight 72447 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72447/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386
flight 116164 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs.
115643
build-amd64-pvop
On 11/8/2017 7:41 AM, Manish Jaggi wrote:
> Hi Sameer
>
> On 9/21/2017 6:07 AM, Sameer Goel wrote:
>> Add support for parsing IORT table to initialize SMMU devices.
>> * The code for creating an SMMU device has been modified, so that the SMMU
>> device can be initialized.
>> * The NAMED NODE cod
flight 116161 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116161/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 116108
test-armhf-armhf-libvirt-xsm 14 sav
This run is configured for baseline tests only.
flight 72446 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72446/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-
flight 116156 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116156/
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-localmigrate/x10 fail REGR. vs.
116126
Tests whic
On 11/14/2017 04:11 AM, Juergen Gross wrote:
> On 13/11/17 19:33, Stefano Stabellini wrote:
>> On Mon, 13 Nov 2017, Juergen Gross wrote:
>>> On 11/11/17 00:57, Stefano Stabellini wrote:
On Tue, 7 Nov 2017, Juergen Gross wrote:
> On 06/11/17 23:17, Stefano Stabellini wrote:
>> mutex_try
On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara
wrote:
> Hi,
Hi Andre
>
> On 13/11/17 19:40, Oleksandr Tyshchenko wrote:
>> On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara
>> wrote:
>>> Hi,
>> Hi Andre,
>>
>>>
>>> thanks very much for your work on this!
>> Thank you for your comments.
>>
>>>
>>
flight 116154 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116154/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are failing
flight 116162 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116162/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 116152 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116152/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 17 guest-start.2fail REGR. vs. 115628
build-amd64-pvops
flight 72445 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72445/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like
72430
test-amd64-i386-am
flight 116158 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116158/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 116150 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 116132
test-amd64-amd64-
Hello,
On Tue, Nov 14, 2017 at 08:25:57AM -0700, Jan Beulich wrote:
> >>> On 14.11.17 at 16:11, wrote:
> > rcu_lock_current_domain is called at the beginning of do_altp2m_op, but
> > the altp2m_vcpu_enable_notify subop handler might skip calling
> > rcu_unlock_domain, possibly hanging the domain
On 11/14/2017 8:32 PM, Julien Grall wrote:
Hi,
On 14/11/17 08:20, Jan Beulich wrote:
On 14.11.17 at 07:53, wrote:
From: Min He
In map_pages_to_xen(), a L2 page table entry may be reset to point to
a superpage, and its corresponding L1 page table need be freed in such
scenario, when these
On 14/11/17 15:11, Adrian Pop wrote:
> rcu_lock_current_domain is called at the beginning of do_altp2m_op, but
> the altp2m_vcpu_enable_notify subop handler might skip calling
> rcu_unlock_domain, possibly hanging the domain altogether.
>
> Signed-off-by: Adrian Pop
Reviewed-by: Andrew Cooper
C
>>> On 14.11.17 at 16:11, wrote:
> rcu_lock_current_domain is called at the beginning of do_altp2m_op, but
> the altp2m_vcpu_enable_notify subop handler might skip calling
> rcu_unlock_domain, possibly hanging the domain altogether.
I fully agree with the change, but the description needs improve
rcu_lock_current_domain is called at the beginning of do_altp2m_op, but
the altp2m_vcpu_enable_notify subop handler might skip calling
rcu_unlock_domain, possibly hanging the domain altogether.
Signed-off-by: Adrian Pop
---
xen/arch/x86/hvm/hvm.c | 8 +++-
1 file changed, 7 insertions(+), 1
Ross Lagerwall writes ("Re: [PATCH] tools: xentoolcore_restrict_all: Do
deregistration before close"):
> On 11/14/2017 12:15 PM, Ian Jackson wrote:
> > + * Note for multi-threaded programs: If xentoolcore_restrict_all is
> > + * called concurrently with a function which /or closes Xen library
>
>
Julien Grall writes ("Re: [PATCH] tools: xentoolcore_restrict_all: Do
deregistration before close"):
> I think this is 4.10 material, xentoolcore was introduced in this
> release and it would be good to have it right from now. I want to
> confirm that you are both happy with that?
Yes, absolute
On 11/14/2017 12:15 PM, Ian Jackson wrote:
Closing the fd before unhooking it from the list runs the risk that a
concurrent thread calls xentoolcore_restrict_all will operate on the
old fd value, which might refer to a new fd by then. So we need to do
it in the other order.
Sadly this weakens t
Hi Wei,
On 14/11/17 13:53, Wei Liu wrote:
On Tue, Nov 14, 2017 at 12:14:14PM +, Julien Grall wrote:
Hi,
On 14/11/17 11:51, Ian Jackson wrote:
Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on
clean-up or failure"):
On 11/10/2017 05:10 PM, Julien Grall wr
Hi,
On 14/11/17 14:02, Wei Liu wrote:
On Tue, Nov 14, 2017 at 12:15:42PM +, Ian Jackson wrote:
Closing the fd before unhooking it from the list runs the risk that a
concurrent thread calls xentoolcore_restrict_all will operate on the
old fd value, which might refer to a new fd by then. So
This run is configured for baseline tests only.
flight 72444 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72444/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-install
On Tue, Nov 14, 2017 at 12:15:42PM +, Ian Jackson wrote:
> Closing the fd before unhooking it from the list runs the risk that a
> concurrent thread calls xentoolcore_restrict_all will operate on the
> old fd value, which might refer to a new fd by then. So we need to do
> it in the other orde
On Tue, Nov 14, 2017 at 05:12:26PM +0530, Bhupinder Thakur wrote:
> Hi,
>
> On 14 Nov 2017 3:35 pm, "Wei Liu" wrote:
>
> > On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote:
> > > Hi Wei,
> > >
> > > Sorry I missed that e-mail.
> > >
> > > On 10/31/2017 10:07 AM, Wei Liu wrote:
> > >
On Tue, Nov 14, 2017 at 12:14:14PM +, Julien Grall wrote:
> Hi,
>
> On 14/11/17 11:51, Ian Jackson wrote:
> > Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active
> > handler on clean-up or failure"):
> > > On 11/10/2017 05:10 PM, Julien Grall wrote:
> > > > Commit 89d55473
On Mon, Nov 13, 2017 at 03:41:24PM +, George Dunlap wrote:
> Signed-off-by: George Dunlap
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Andrew Cooper
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Konrad Wilk
> CC: Tim Deegan
> CC: Rich Persaud
> CC: Marek Marczykowski-Górecki
> CC: C
Hi Manish,
On 08/11/17 14:38, Manish Jaggi wrote:
ACPI/IORT Support in Xen.
--
Draft 2
Revision History:
Changes since v1-
- Modified IORT Parsing data structures.
- Added RID->StreamID and RID->DeviceID map as per Andre's suggestion.
- Added reference code which c
flight 116153 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116153/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 115476
build-armhf-libvirt
On Wed, Nov 1, 2017 at 5:05 PM, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Changes since initial:
> * add setting backend-type to xenstore
> * add id field to indentify the vkb device on backend side
>
> Oleksandr Grytsov (6):
> libxl: move vkb device to libxl_vkb.c
> libxl: fi
On Wed, Nov 1, 2017 at 5:04 PM, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> This patch set adds PV sound device support to xl.cfg and xl.
> See sndif.h for protocol implementation details.
>
> Changes since initial:
> * fix code style
> * change unique-id from int to string (to make
Hi,
On 14/11/17 08:20, Jan Beulich wrote:
On 14.11.17 at 07:53, wrote:
From: Min He
In map_pages_to_xen(), a L2 page table entry may be reset to point to
a superpage, and its corresponding L1 page table need be freed in such
scenario, when these L1 page table entries are mapping to consecuti
Closing the fd before unhooking it from the list runs the risk that a
concurrent thread calls xentoolcore_restrict_all will operate on the
old fd value, which might refer to a new fd by then. So we need to do
it in the other order.
Sadly this weakens the guarantee provided by xentoolcore_restrict
Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler
on clean-up or failure"):
> Now that I look at it, a similar scenario can happen during open. Since
> the handle is registered before it is actually opened, a concurrent
> xentoolcore_restrict_all() will try to restr
Hi,
On 14/11/17 11:51, Ian Jackson wrote:
Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on
clean-up or failure"):
On 11/10/2017 05:10 PM, Julien Grall wrote:
Commit 89d55473ed16543044a31d1e0d4660cf5a3f49df "xentoolcore_restrict_all:
Implement for libxenevtchn
On 11/14/2017 11:51 AM, Ian Jackson wrote:
Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on
clean-up or failure"):
On 11/10/2017 05:10 PM, Julien Grall wrote:
Commit 89d55473ed16543044a31d1e0d4660cf5a3f49df "xentoolcore_restrict_all:
Implement for libxenevtchn
On 14/11/17 12:43, Quan Xu wrote:
>
>
> On 2017/11/14 18:27, Juergen Gross wrote:
>> On 14/11/17 10:38, Quan Xu wrote:
>>>
>>> On 2017/11/14 15:30, Juergen Gross wrote:
On 14/11/17 08:02, Quan Xu wrote:
> On 2017/11/13 18:53, Juergen Gross wrote:
>> On 13/11/17 11:06, Quan Xu wrote:
Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler
on clean-up or failure"):
> On 11/10/2017 05:10 PM, Julien Grall wrote:
> > Commit 89d55473ed16543044a31d1e0d4660cf5a3f49df "xentoolcore_restrict_all:
> > Implement for libxenevtchn" added a call to register allowing t
On 2017/11/14 18:27, Juergen Gross wrote:
On 14/11/17 10:38, Quan Xu wrote:
On 2017/11/14 15:30, Juergen Gross wrote:
On 14/11/17 08:02, Quan Xu wrote:
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for
Hi,
On 14 Nov 2017 3:35 pm, "Wei Liu" wrote:
> On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote:
> > Hi Wei,
> >
> > Sorry I missed that e-mail.
> >
> > On 10/31/2017 10:07 AM, Wei Liu wrote:
> > > Change the tag to for-4.10.
> > >
> > > Julien, this is needed to fix vuart emulation.
flight 116146 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116146/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 7 xen-boot fail REGR. vs. 116126
Tests which did n
Hi,
On 13/11/17 19:40, Oleksandr Tyshchenko wrote:
> On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara
> wrote:
>> Hi,
> Hi Andre
>
>>
>> thanks very much for your work on this!
> Thank you for your comments.
>
>>
>> On 09/11/17 17:09, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>
On 14/11/17 10:38, Quan Xu wrote:
>
>
> On 2017/11/14 15:30, Juergen Gross wrote:
>> On 14/11/17 08:02, Quan Xu wrote:
>>>
>>> On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
> From: Quan Xu
>
> So far, pv_idle_ops.poll is the only ops for pv_idle. .p
On 2017/11/14 16:22, Wanpeng Li wrote:
2017-11-14 16:15 GMT+08:00 Quan Xu :
On 2017/11/14 15:12, Wanpeng Li wrote:
2017-11-14 15:02 GMT+08:00 Quan Xu :
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for
flight 116148 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote:
> Hi Wei,
>
> Sorry I missed that e-mail.
>
> On 10/31/2017 10:07 AM, Wei Liu wrote:
> > Change the tag to for-4.10.
> >
> > Julien, this is needed to fix vuart emulation.
>
> To confirm, only patch #1 is candidate for Xen 4.10, righ
On Mon, Nov 13, 2017 at 02:34:42PM -0800, Alistair Francis wrote:
> Replace all occurs of __FUNCTION__ except for the check in checkpatch
> with the non GCC specific __func__.
>
> One line in hcd-musb.c was manually tweaked to pass checkpatch.
>
> Signed-off-by: Alistair Francis
> Cc: Gerd Hoffm
On 2017/11/14 15:30, Juergen Gross wrote:
On 14/11/17 08:02, Quan Xu wrote:
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we en
flight 116145 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116145/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 116104 pass in
116145
test-armhf-armhf-xl-arndale
On 13/11/17 19:33, Stefano Stabellini wrote:
> On Mon, 13 Nov 2017, Juergen Gross wrote:
>> On 11/11/17 00:57, Stefano Stabellini wrote:
>>> On Tue, 7 Nov 2017, Juergen Gross wrote:
On 06/11/17 23:17, Stefano Stabellini wrote:
> mutex_trylock() returns 1 if you take the lock and 0 if not.
flight 116140 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116140/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 116106 pass
in 116140
test-amd64-amd64-xl-qcow
2017-11-14 16:15 GMT+08:00 Quan Xu :
>
>
> On 2017/11/14 15:12, Wanpeng Li wrote:
>>
>> 2017-11-14 15:02 GMT+08:00 Quan Xu :
>>>
>>>
>>> On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
>
> From: Quan Xu
>
> So far, pv_idle_ops.poll is the only
>>> On 14.11.17 at 07:53, wrote:
> In modify_xen_mappings(), a L1/L2 page table shall be freed,
> if all entries of this page table are empty. Corresponding
> L2/L3 PTE will need be cleared in such scenario.
>
> However, concurrent paging structure modifications on different
> CPUs may cause the
>>> On 14.11.17 at 07:53, wrote:
> From: Min He
>
> In map_pages_to_xen(), a L2 page table entry may be reset to point to
> a superpage, and its corresponding L1 page table need be freed in such
> scenario, when these L1 page table entries are mapping to consecutive
> page frames and having the
On 2017/11/14 15:12, Wanpeng Li wrote:
2017-11-14 15:02 GMT+08:00 Quan Xu :
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we en
61 matches
Mail list logo
