flight 138599 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 138562
Tests which did
flight 138617 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138617/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 138591 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-i386-prev 6
flight 138596 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138596/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
138461
Tests which did
flight 138587 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138587/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 138498
On Fri, 28 Jun 2019, Denis Obrezkov wrote:
> Hi Iain,
>
> On 6/28/19 7:25 PM, Iain Hunter wrote:
> > Hi Stefano,
> > It was a patchset I'd circulated earlier in the GSoC process.
> > Basically the partial port of Xen on X15 I'd done last year. The build
> > script is the reference for which
On Fri, 28 Jun 2019, Andrew Cooper wrote:
> A Travis randconfig build notices:
>
> optee.c: In function ‘allocate_and_pin_shm_rpc’:
> optee.c:383:13: error: format ‘%lx’ expects argument of type
>‘long unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
>
flight 138610 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138610/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
> On Jun 28, 2019, at 5:32 PM, George Dunlap wrote:
>
> On 6/28/19 9:25 AM, Nicolas Belouin wrote:
>> The Go bindings for libxl miss functions from libxl_utils, let's start
>> with the simple libxl_domid_to_name and its counterpart
>> libxl_name_to_domid.
>>
>> Signed-off-by: Nicolas Belouin
This is an informational post about AMD Secure Encrypted Virtualization -
Encrypted State.
In addition to the Secure Encrypted Virtualization (SEV) feature, AMD EPYC
processors also provide a feature called Secure Encrypted Virtualization -
Encrypted State (SEV-ES). Building on the memory
flight 138592 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 137600
build-arm64-xsm
flight 138584 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138584/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
Hi Denis,
Agreed. I would continue as you are, just remembering that if you have
an issue there might be a patch for it already and have a look at the
patches.
Iain
On Fri, 28 Jun 2019 at 19:31, Denis Obrezkov wrote:
>
> Hi Iain,
>
> On 6/28/19 7:25 PM, Iain Hunter wrote:
> > Hi Stefano,
> > It
On Fri 28-06-19 19:38:13, Juergen Gross wrote:
> On 28.06.19 17:17, Michal Hocko wrote:
> > On Thu 20-06-19 18:08:21, Juergen Gross wrote:
> > > Commit 0e56acae4b4dd4a9 ("mm: initialize MAX_ORDER_NR_PAGES at a time
> > > instead of doing larger sections") is causing a regression on some
> > >
Hi Iain,
On 6/28/19 7:25 PM, Iain Hunter wrote:
> Hi Stefano,
> It was a patchset I'd circulated earlier in the GSoC process.
> Basically the partial port of Xen on X15 I'd done last year. The build
> script is the reference for which patches were actually used.
> Iain
I believe the reason we
Hello,
I need your help to pinpoint the root cause of a problem. To my
understanding vfree should be used when allocating memory with vmalloc.
But, I have the following scenario which results in a XEN crash:
- allocate a number of frames using vmalloc (vzalloc) (e.g. using a
domctl) and assign
On 28.06.19 17:17, Michal Hocko wrote:
On Thu 20-06-19 18:08:21, Juergen Gross wrote:
Commit 0e56acae4b4dd4a9 ("mm: initialize MAX_ORDER_NR_PAGES at a time
instead of doing larger sections") is causing a regression on some
systems when the kernel is booted as Xen dom0.
The system will just
Hi Stefano,
It was a patchset I'd circulated earlier in the GSoC process.
Basically the partial port of Xen on X15 I'd done last year. The build
script is the reference for which patches were actually used.
Iain
On Fri, 28 Jun 2019 at 17:02, Stefano Stabellini wrote:
>
> Hi Iain,
>
> Where is
On 6/28/19 9:31 AM, Nicolas Belouin wrote:
> Newer versions of Go have become stricter on enforcing the no implicit
> conversions policy when using CGo.
> Specifically, the following two conversions are no longer allowed:
>
> - unsafe.Pointer being automatically cast to any C pointer
> - A
flight 138609 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138609/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 6/28/19 9:25 AM, Nicolas Belouin wrote:
> The Go bindings for libxl miss functions from libxl_utils, let's start
> with the simple libxl_domid_to_name and its counterpart
> libxl_name_to_domid.
>
> Signed-off-by: Nicolas Belouin
Just for future reference, below your SoB, it's good practice
Hi Iain,
Where is the patch you mentioned? Maybe you forgot to attach it to the
email?
Cheers,
Stefano
On Fri, 28 Jun 2019, Iain Hunter wrote:
> Stefano, Denis,
>
> I achieved that with patch
> patches/xen/0003-add-PRCM_MPU-to-memory-translation-for-AM572x.patch.
> This just adds
>
On Thu, Jun 20, 2019 at 01:06:21PM +0100, Andy Cooper wrote:
> Following on from c/s 7d161f6537 "x86/svm: Fix svm_vmcb_dump() when used in
> current context", there is now only a single user of svm_vmsave() remaining in
> the tree, with all users moved to svm_vm{load,save}_pa().
>
> nv->nv_n1vmcx
On Thu 20-06-19 18:08:21, Juergen Gross wrote:
> Commit 0e56acae4b4dd4a9 ("mm: initialize MAX_ORDER_NR_PAGES at a time
> instead of doing larger sections") is causing a regression on some
> systems when the kernel is booted as Xen dom0.
>
> The system will just hang in early boot.
>
> Reason is
flight 138608 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138608/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 138577 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138577/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
A Travis randconfig build notices:
optee.c: In function ‘allocate_and_pin_shm_rpc’:
optee.c:383:13: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
gdprintk(XENLOG_WARNING, "Guest tries to use the same RPC SHM cookie
On Fri, Jun 28, 2019 at 10:40:02AM +, Jan Beulich wrote:
> On 28.06.2019 12:15, Roger Pau Monné wrote:
> > On Fri, Jun 28, 2019 at 09:29:53AM +, Jan Beulich wrote:
> >> >>> On 26.06.19 at 15:55, wrote:
> > TBH I would like some guidelines about how CROSS_COMPILE is supposed
> > to be
flight 138580 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138580/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c54c85621826ace8684879fef9eb8ba7f49cfb54
baseline version:
ovmf
On 28.06.2019 12:15, Roger Pau Monné wrote:
> On Fri, Jun 28, 2019 at 09:29:53AM +, Jan Beulich wrote:
>> >>> On 26.06.19 at 15:55, wrote:
>> > --- a/Config.mk
>> > +++ b/Config.mk
>> > @@ -39,22 +39,12 @@ DESTDIR ?= /
>> > # Allow phony attribute to be listed as dependency
>>> On 21.06.19 at 11:36, wrote:
> xen/gnttab: Reduce complexity when reading grant_entry_header_t
> xen/gnttab: Reduce code volume when using union grant_combo
>...
> xen/gnttab: Fold adjacent calls to gnttab_clear_flags()
These three
Reviewed-by: Jan Beulich
Jan
>>> On 21.06.19 at 11:36, wrote:
> --- a/xen/include/asm-x86/grant_table.h
> +++ b/xen/include/asm-x86/grant_table.h
> @@ -60,14 +60,11 @@ static inline int replace_grant_host_mapping(uint64_t
> addr, mfn_t frame,
>
> #define gnttab_mark_dirty(d, f) paging_mark_dirty(d, f)
>
> -static
On Fri, Jun 28, 2019 at 09:40:59AM +, Jan Beulich wrote:
> >>> On 26.06.19 at 15:55, wrote:
> > and instead export them from the top-level Xen makefile.
>
> Would be helpful to know what problem this solves. Adding
> "random" exports _can_ have undesirable side effects, so we
> shouldn't
On Fri, Jun 28, 2019 at 09:29:53AM +, Jan Beulich wrote:
> >>> On 26.06.19 at 15:55, wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -39,22 +39,12 @@ DESTDIR ?= /
> > # Allow phony attribute to be listed as dependency rather than fake
> target
> > .PHONY: .phony
> >
> >
>>> On 26.06.19 at 15:55, wrote:
> and instead export them from the top-level Xen makefile.
Would be helpful to know what problem this solves. Adding
"random" exports _can_ have undesirable side effects, so we
shouldn't make such a change without reason.
Jan
>>> On 26.06.19 at 15:55, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -39,22 +39,12 @@ DESTDIR ?= /
> # Allow phony attribute to be listed as dependency rather than fake
target
> .PHONY: .phony
>
> -# If we are not cross-compiling, default HOSTC{C/XX} to C{C/XX}
> -ifeq
flight 138573 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138573/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
On Thu, 27 Jun 2019 18:58:53 +0200,
Colin King wrote:
>
> From: Colin Ian King
>
> Shifting the integer value 1 is evaluated using 32-bit
> arithmetic and then used in an expression that expects a 64-bit
> value, so there is potentially an integer overflow. Fix this
> by using the BIT_ULL macro
Newer versions of Go have become stricter on enforcing the no implicit
conversions policy when using CGo.
Specifically, the following two conversions are no longer allowed:
- unsafe.Pointer being automatically cast to any C pointer
- A pointer type other than unsafe.Pointer being automatically
Stefano, Denis,
I achieved that with patch
patches/xen/0003-add-PRCM_MPU-to-memory-translation-for-AM572x.patch.
This just adds
.specific_mapping=omap5_specific_mapping
to DRA7 platform.
Iain
On Fri, 28 Jun 2019 at 01:33, Stefano Stabellini wrote:
>
> Writing here a summary of the follow-up
40 matches
Mail list logo
