flight 145908 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
It is now more covenient for me to use my Amazon address.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Wei Liu
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertio
As agreed during the 2020-01 community call [1] this patch introduces a
changelog, based on the principles explained at keepachangelog.com [2].
A new MAINTAINERS entry is also added, with myself as (currently sole)
maintainer.
[1] See C.2 at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6H
On 10.01.2020 10:12, Paul Durrant wrote:
> --- /dev/null
> +++ b/CHANGELOG.md
> @@ -0,0 +1,14 @@
> +# Changelog
> +
> +All notable changes to Xen will be documented in this file.
How do we qualify what's "notable" and what's not? IOW I wonder
whether "All" should be dropped, or be replaced by "Som
On 10/01/2020, 09:12, "Paul Durrant" wrote:
As agreed during the 2020-01 community call [1] this patch introduces a
changelog, based on the principles explained at keepachangelog.com [2].
A new MAINTAINERS entry is also added, with myself as (currently sole)
maintainer.
> -Original Message-
> From: Jan Beulich
> Sent: 10 January 2020 09:52
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu ; Lars Kurth
>
> Subject: Re: [PATCH]
flight 145906 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145906/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 145842
test-armhf-armhf-libvirt-raw 13 saveresto
Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for XENVER_commandline and XENVER_build_id as well.
Introduce xsm_filter_denied() to hvmloader to remove "" string
from guest's DMI t
On Thu, Jan 09, 2020 at 04:41:06PM +, Wei Liu wrote:
> On Thu, Jan 09, 2020 at 02:02:55PM +, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Wei Liu
> > > Sent: 09 January 2020 13:52
> > > To: Durrant, Paul
> > > Cc: xen-devel@lists.xenproject.org; Ian Jackson
> > > ; We
On 10/01/2020 10:37, Sergey Dyasli wrote:
> Hide the following information that can help identify the running Xen
> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
> Add explicit cases for XENVER_commandline and XENVER_build_id as well.
>
> Introduce xsm_filter_denied()
flight 145915 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145915/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 09/01/2020 09:15, Jürgen Groß wrote:
> On 08.01.20 16:20, Sergey Dyasli wrote:
>> This enables to use Outline instrumentation for Xen PV kernels.
>>
>> KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
>> and hence disabled.
>>
>> Signed-off-by: Sergey Dyasli
>> ---
>> RFC -
On 10.01.2020 11:37, Sergey Dyasli wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -995,6 +995,12 @@ void hvmloader_acpi_build_tables(struct acpi_config
> *config,
> hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->vm_gid_addr);
> }
>
> +vo
> -Original Message-
> From: Xen-devel On Behalf Of
> David Woodhouse
> Sent: 08 January 2020 17:25
> To: Xen-devel
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; p...@xen.org; Ian Jackson
> ; Jan Beulich ; Roger Pau
> Mon
flight 145909 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145909/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
On 09/01/2020 23:27, Boris Ostrovsky wrote:
>
>
> On 1/8/20 10:20 AM, Sergey Dyasli wrote:
>> @@ -1943,6 +1973,15 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
>> unsigned long max_pfn)
>> if (i && i < pgd_index(__START_KERNEL_map))
>> init_top_pgt[i] = ((pgd_t *)xen_star
On Fri, 2020-01-10 at 11:15 +, Durrant, Paul wrote:
> > -Original Message-
> > From: Xen-devel On Behalf
> > Of
> > David Woodhouse
> > Sent: 08 January 2020 17:25
> > To: Xen-devel
> > Cc: Stefano Stabellini ; Julien Grall
> > ; Wei Liu ; Konrad Rzeszutek Wilk
> > ; George Dunlap <
>
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
bas
flight 145923 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
No functional change.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_event.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 05559cad9a..4d57843cce 100644
--- a/tools/libxl/libxl_event.c
+++
This is a very common exit pattern. We are going to want to change
this pattern. So we should make it into a macro of its own.
No functional change.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_event.c| 18 ++
tools/libxl/libxl_fork.c | 6 ++
tools/libxl/libxl
We are going to use this a bit more widely. Make the name more
general.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl.c | 4 ++--
tools/libxl/libxl_event.c| 8
tools/libxl/libxl_internal.h | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/
If the application calls libxl with ao_how==0 and also makes calls
like _occurred, libxl will sometimes get stuck.
The bug happens as follows (for example):
Thread A
libxl_do_thing(,ao_how==0)
libxl_do_thing starts, sets up some callbacks
libxl_do_thing exit path calls AO_I
If the application uses libxl_osevent_beforepoll, a similar hang is
possible to the one described and fixed in
libxl: event: Fix hang when mixing blocking and eventy calls
Application behaviour would have to be fairly unusual, but it
doesn't seem sensible to just leave this latent bug.
We fix t
This is only for deregistration. We are going to add another variable
for new events, with different semantics, and this overly-general name
will become confusing.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_event.c| 8
tools/libxl/libxl_internal.h | 6 +++---
2 files changed,
The meat here, including a description of the bug, is in:
libxl: event: Fix hang when mixing blocking and eventy calls
I have compiled this but not tested it. We do not have a good test
suite for this event stuff. (And races etc are hard to test.)
George, can you check to see whether it fixes
Track in userland whether the poller pipe is nonempty. This saves us
writing many many bytes to the pipe if nothing ever reads them.
This is going to be relevant in a moment, where we are going to create
a situation where this will happen quite a lot.
Signed-off-by: Ian Jackson
---
tools/libxl
If a timer event callback causes this poller to be woken (not very
unlikely) we would go round the poll loop twice rather than once.
Do the poller pipe emptying at the end; this is slightly more
efficient because it can't cause any callbacks, so it happens after
all the callbacks have been run.
(
flight 145903 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145903/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail in 145879 pass in 145903
test-amd64-amd64-qemuu-nested-in
On 09/01/2020 13:36, Paul Durrant wrote:
> On Wed, 8 Jan 2020 at 15:21, Sergey Dyasli wrote:
>>
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
>> allocations are aligned to the next power of 2 of the size does not
>> hold. Therefore, handle gran
flight 145926 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145926/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
bas
flight 145930 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 1/10/20 11:02 AM, Andrew Cooper wrote:
> On 10/01/2020 10:37, Sergey Dyasli wrote:
>> Hide the following information that can help identify the running Xen
>> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
>> Add explicit cases for XENVER_commandline and XENVER_build
Hey Peter,
On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> > From: Eduardo Valentin
> >
> > System instability are seen during resume from hibernation when system
> > is under heavy CPU load. This is due to the l
On 10.01.2020 16:28, George Dunlap wrote:
> On 1/10/20 11:02 AM, Andrew Cooper wrote:
>> On 10/01/2020 10:37, Sergey Dyasli wrote:
>>> Hide the following information that can help identify the running Xen
>>> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
>>> Add explic
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and ot
Current implementation of hvm_flush_vcpu_tlb is highly inefficient.
First of all the call to flush_tlb_mask is completely useless when
trying to flush the TLB of HVM guests, as this TLB flush is executed in
root mode, and hence doesn't flush any guest state cache.
Secondly, calling paging_update_
Hello,
The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.
Patch #2 is likely the most controversial one, as it changes the
implementation of assisted TLB flushes. I have to admit I haven't been
able to figure
On 10.01.2020 17:04, Roger Pau Monne wrote:
> Patch #2 is likely the most controversial one, as it changes the
> implementation of assisted TLB flushes. I have to admit I haven't been
> able to figure out why HVM guest context flushes issued a
> flush_tlb_mask, and the commit introducing such behav
On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
> Changes since V6:
> - Remove stray spaces
> - Use ARRAY_SIZE(d->arch.altp2m_p2m) insead of MAX_ALTP2M.
I'm not utterly confused:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -366,11 +366,13 @@ long
On Fri, Jan 10, 2020 at 05:08:16PM +0100, Jan Beulich wrote:
> On 10.01.2020 17:04, Roger Pau Monne wrote:
> > Patch #2 is likely the most controversial one, as it changes the
> > implementation of assisted TLB flushes. I have to admit I haven't been
> > able to figure out why HVM guest context flu
On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not break in case
> of a error and it is doing a best
flight 145934 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
>
> This patch assigns default_access to p2m->default_access at the time of
> initializing a new altp2m view.
>
> Signed-off-by: Alexandru Isaila
The tiny part
On 09.01.2020 20:32, Andrew Cooper wrote:
> These are left over from c/s b2804422 "x86: make Xen early boot code
> relocatable", which made it possible for Xen not to be in the bottom 16M.
>
> Nothing using the mappings any more. Build them in the directmap when walking
> the E820 table along wit
On 08/01/2020, 16:52, "Jürgen Groß" wrote:
Just had a chat with Lars on IRC, which might be of common
interest (and Lars asked me to post it to xen-devel):
(17:00:16) juergen_gross: lars_kurth: any idea why
./scripts/add_maintainers.pl would add a "Cc:" without a mail add
On 10.01.20 16:56, Jan Beulich wrote:
On 10.01.2020 16:28, George Dunlap wrote:
On 1/10/20 11:02 AM, Andrew Cooper wrote:
On 10/01/2020 10:37, Sergey Dyasli wrote:
Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XE
On 09.01.2020 20:32, Andrew Cooper wrote:
> The need for Xen to be identity mapped into the bootmap is not obvious, and
> differs between the MB and EFI boot paths.
>
> The EFI side is further complicated by an attempt to cope with with l2_bootmap
> only being 4k long. This is undocumented, confu
On 09.01.2020 20:32, Andrew Cooper wrote:
> Now that NULL will fault at boot, there is no need for a special constant to
> signify "current not set up yet".
>
> Since c/s fae249d23413 "x86/boot: Rationalise stack handling during early
> boot", the BSP cpu_info block is now consistently zero, so dr
On 1/10/20 4:45 PM, Jürgen Groß wrote:
> On 10.01.20 16:56, Jan Beulich wrote:
>> On 10.01.2020 16:28, George Dunlap wrote:
>>> On 1/10/20 11:02 AM, Andrew Cooper wrote:
On 10/01/2020 10:37, Sergey Dyasli wrote:
> Hide the following information that can help identify the running Xen
>
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
bas
Paul Durrant writes ("[PATCH] tools/Rules.mk: fix distclean"):
> Running 'make distclean' under tools will currently result in:
>
> tools/Rules.mk:245: *** You have to run ./configure before building or
> installing the tools. Stop.
>
> This patch adds 'distclean', 'subdir-distclean%' and 'subd
On 10/01/2020 09:12, Paul Durrant wrote:
> As agreed during the 2020-01 community call [1] this patch introduces a
> changelog, based on the principles explained at keepachangelog.com [2].
> A new MAINTAINERS entry is also added, with myself as (currently sole)
> maintainer.
>
> [1] See C.2 at http
George Dunlap writes ("[PATCH v2 1/2] libxl: Get rid of some trailing
whitespace"):
> No functional changes.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 1/9/20 12:12 PM, George Dunlap wrote:
> libxl needs to be able to know when processes it forks have completed.
>
> At the moment, libxl has two basic mode (with some variations). In
> one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
> SIGCHLD signal handler, and also handles the
On 10/01/2020 02:30, Tamas K Lengyel wrote:
> The library has been largely untouched for over a decade at this point, it is
> undocumented and it's unclear what it was originally used for. Remove it from
> tree, if anyone needs it in the future it can be carved out from git history.
>
> Signed-off-
Hi all,
On 08/01/2020 23:14, Julien Grall wrote:
On Wed, 8 Jan 2020 at 21:40, osstest service owner
wrote:
flight 145796 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145796/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Fri, Jan 10, 2020 at 10:59 AM Andrew Cooper
wrote:
>
> On 10/01/2020 02:30, Tamas K Lengyel wrote:
> > The library has been largely untouched for over a decade at this point, it
> > is
> > undocumented and it's unclear what it was originally used for. Remove it
> > from
> > tree, if anyone ne
flight 145939 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145935 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
Anchal,
Anchal Agarwal writes:
> On Thu, Jan 09, 2020 at 01:07:27PM +0100, Thomas Gleixner wrote:
>> Anchal Agarwal writes:
>> So either you can handle it purely on the XEN side without touching any
>> core state or you need to come up with some way of letting the core code
>> know that it shoul
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Cornelia Huck
CC: Eric Blake
CC: Kevin Wolf
CC: Max Reitz
CC: Greg Kurz
CC: Stefan Hajnoczi
CC: Stefano Stabellini
CC: Anthony Perard
CC: Paul Durrant
CC: "Philippe Mathieu-Daudé"
CC: Laszlo Ersek
CC: Gerd Hoffmann
CC: Stefan Berger
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal & error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information is
Hi all!
Now, when preparations from
[RFC v5 000/126] error: auto propagated local_err
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg02771.html
https://src.openvz.org/scm/~vsementsov/qemu.git #tag up-auto-local-err-v5
, after some iterations, are finally merged, let's proceed with th
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
CC: Cornelia Huck
CC: Eric Blake
CC: Kevin Wolf
CC: Max Reitz
CC: Greg Kurz
CC: Stefan Hajnoczi
CC: Stefano Stabellini
CC: Anthony Perard
CC: Paul Durrant
CC: "Philippe Mathieu-Daudé"
CC: Laszlo Ersek
CC: Gerd Hoffmann
CC: Stefan Berger
> On 10 Jan 2020, at 17:54, Andrew Cooper wrote:
>
> On 10/01/2020 09:12, Paul Durrant wrote:
>> As agreed during the 2020-01 community call [1] this patch introduces a
>> changelog, based on the principles explained at keepachangelog.com [2].
>> A new MAINTAINERS entry is also added, with myse
Patchew URL:
https://patchew.org/QEMU/20200110194158.14190-1-vsement...@virtuozzo.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Xen-devel] [PATCH v6 00/11] error: auto propagated local_err part I
Type: series
Message-id: 202001
From: Lars Kurth
Prior to this change e-mail addresses of the form "display name
" would result into empty output. Also see
https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00753.html
Signed-off-by: Lars Kurth
---
CC: jgr...@suse.com
---
scripts/get_maintainer.pl | 2 +-
1 file
flight 145947 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145947/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145946 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145946/
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 1
flight 145948 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
Signed-off-by: Julien Grall
---
xen/common/sched_rt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index b2b29481f3..c40a7e4990 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -122,7 +122,7 @@
*/
/*
* RTDS
On Fri, Jan 10, 2020 at 08:13:16PM +0100, Thomas Gleixner wrote:
> Anchal,
>
> Anchal Agarwal writes:
> > On Thu, Jan 09, 2020 at 01:07:27PM +0100, Thomas Gleixner wrote:
> >> Anchal Agarwal writes:
> >> So either you can handle it purely on the XEN side without touching any
> >> core state or y
flight 145954 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145954/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Fri, Jan 10, 2020 at 2:23 PM Julien Grall wrote:
>
> Signed-off-by: Julien Grall
> ---
> xen/common/sched_rt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index b2b29481f3..c40a7e4990 100644
> --- a/xen/common/sched_
(+ Meng)
Hi,
Sorry I forgot to cc the RTDS scheduler maintainer.
On 10/01/2020 18:24, Julien Grall wrote:
Hi all,
On 08/01/2020 23:14, Julien Grall wrote:
On Wed, 8 Jan 2020 at 21:40, osstest service owner
wrote:
flight 145796 xen-unstable real [real]
http://logs.test-lab.xenproject.org/o
flight 145959 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145959/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
MSI(-X) enable flags in the PCI config space. This adds an attribute
'allow_interrupt_control' which when set for a PCI device allows writes
to this flag(s). The toolstack will need to set this for stubdoms.
When enabled, guest
On 1/10/20 9:28 AM, George Dunlap wrote:
On 1/10/20 11:02 AM, Andrew Cooper wrote:
On 10/01/2020 10:37, Sergey Dyasli wrote:
Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for
On 1/10/20 4:37 AM, Sergey Dyasli wrote:
Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
Add explicit cases for XENVER_commandline and XENVER_build_id as well.
Introduce xsm_filter_denied() to hvm
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git:
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sergey-Dyasli/basic-KASAN-support-for-Xen-PV-domains/20200110-042623
bas
flight 145964 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 145975 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
87 matches
Mail list logo
