On 15.04.2020 20:37, Hongyan Xia wrote:
> From: Wei Liu
>
> Also, introduce lYe_from_lXe() macros which do not rely on the direct
> map when walking page tables. Unfortunately, they cannot be inline
> functions due to the header dependency on domain_page.h, so keep them as
> macros just like map_
On 15.04.2020 20:37, Hongyan Xia wrote:
> From: Wei Liu
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On 15.04.2020 19:39, Andrew Cooper wrote:
> The PERFC_INCR() macro uses current->processor, but current is not valid
> during early boot. This causes the following crash to occur if
> e.g. rdmsr_safe() has to recover from a #GP fault.
>
> (XEN) Early fatal page fault at e008:82d0803b1a39
>
On 15.04.2020 18:58, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 02:46:42PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
>>> still mandatory for if_changed (or cmd) macro to work.
>
On 16/04/2020 08:19, Jan Beulich wrote:
> On 15.04.2020 19:39, Andrew Cooper wrote:
>> The PERFC_INCR() macro uses current->processor, but current is not valid
>> during early boot. This causes the following crash to occur if
>> e.g. rdmsr_safe() has to recover from a #GP fault.
>>
>> (XEN) Earl
Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing additional information
about the selected granularity. Messages now look like these:
1. boot
(XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler (credit) in
core-schedulin
Hi Andrew,
On 15/04/2020 18:39, Andrew Cooper wrote:
The PERFC_INCR() macro uses current->processor, but current is not valid
during early boot. This causes the following crash to occur if
e.g. rdmsr_safe() has to recover from a #GP fault.
(XEN) Early fatal page fault at e008:82d0803b1a
On 16.04.2020 10:19, Andrew Cooper wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -679,7 +679,11 @@ handle_exception_saved:
> 1: movq %rsp,%rdi
> movzbl UREGS_entry_vector(%rsp),%eax
> leaq exception_table(%rip),%rdx
> - PERFC_IN
On 16/04/2020 09:35, Jan Beulich wrote:
> On 16.04.2020 10:19, Andrew Cooper wrote:
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -679,7 +679,11 @@ handle_exception_saved:
>> 1: movq %rsp,%rdi
>> movzbl UREGS_entry_vector(%rsp),%eax
>> leaq
On 16.04.20 10:33, Sergey Dyasli wrote:
Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing additional information
about the selected granularity. Messages now look like these:
1. boot
(XEN) [00089808f0ea7496] Using scheduler: SMP Cr
On 15/04/2020 02:02, Stefano Stabellini wrote:
Hi all,
This series adds support for 1:1 mapping (guest physical == physical)
the memory of dom0less domUs. The memory ranges assigned to a domU can be
explicitly chosen by the user at boot time.
This is desirable in cases where an IOMMU is not
On 16/04/2020 09:57, Jürgen Groß wrote:
> On 16.04.20 10:33, Sergey Dyasli wrote:
>> Currently it might be not obvious which scheduling mode is being used
>> by the scheduler. Alleviate this by printing additional information
>> about the selected granularity. Messages now look like these:
>>
>> 1.
On 16.04.20 11:20, Sergey Dyasli wrote:
On 16/04/2020 09:57, Jürgen Groß wrote:
On 16.04.20 10:33, Sergey Dyasli wrote:
Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing additional information
about the selected granularity. Messa
On 16/04/2020 10:25, Jürgen Groß wrote:
> On 16.04.20 11:20, Sergey Dyasli wrote:
>> On 16/04/2020 09:57, Jürgen Groß wrote:
>>> On 16.04.20 10:33, Sergey Dyasli wrote:
Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing addit
This is the first series of XTF patches I intend to send.
It covers some relatively small fixes to handling of PV console
by HVM guests, as well as adding serial consol support.
Paul Semel (2):
Enabled serial writing for hvm guests
setup: Setup PV console for HVM guests on xen >4.2
Pawel Wiec
The explicit LFCR sequence guarantees proper line by line formatting
in the output.
The '\n' character alone on some terminals is not automatically
converted to LFCR.
Signed-off-by: Pawel Wieczorkiewicz
---
common/libc/vsnprintf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/c
These are just a simple macros obtaining major, minor values as
returned by xen_version hypercall.
Signed-off-by: Pawel Wieczorkiewicz
---
include/xtf/lib.h| 3 +++
tests/xsa-213/main.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/xtf/lib.h b/include/xtf/l
From: Paul Semel
Xen 4.2 requires a workaround that does not setup PV console
for HVM guests. However, newer Xen versions do not have that
limitation and should always have the PV console setup.
In arch_setup() detects Xen version by issuing xen_version hypercall
and optionally passes the versio
From: Paul Semel
setup.c: PV console writing is not working in Xen 4.2 for hvm
guests, so we make xtf write to COM1 serial port to get its output
Signed-off-by: Paul Semel
Signed-off-by: Pawel Wieczorkiewicz
---
arch/x86/setup.c | 14 ++
1 file changed, 14 insertions(+)
diff --gi
On Thu, Apr 16, 2020 at 09:36:15AM +0200, Jan Beulich wrote:
> On 15.04.2020 18:58, Anthony PERARD wrote:
> > On Wed, Apr 08, 2020 at 02:46:42PM +0200, Jan Beulich wrote:
> >> On 31.03.2020 12:30, Anthony PERARD wrote:
> >>> - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line
On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> The explicit LFCR sequence guarantees proper line by line formatting
> in the output.
> The '\n' character alone on some terminals is not automatically
> converted to LFCR.
>
> Signed-off-by: Pawel Wieczorkiewicz
Up until now, all console destina
On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> From: Paul Semel
>
> setup.c: PV console writing is not working in Xen 4.2 for hvm
> guests,
What is not working about it?
> so we make xtf write to COM1 serial port to get its output
>
> Signed-off-by: Paul Semel
> Signed-off-by: Pawel Wieczo
On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> @@ -272,9 +274,23 @@ void arch_setup(void)
>
> init_hypercalls();
>
> -if ( !is_initdomain() )
> +xen_version = hypercall_xen_version(XENVER_version, NULL);
> +if ( version )
> +*version = xen_version;
> +
> +/*
> +
From: Julien Grall
At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked const.
Thankfully, no users of the helper will do that. Rather than hoping this
can be caught during review, harden copy_to_guest_offset() so the build
will fail if such users
Hi,
Gentle ping. I am missing reviews for the OCaml part.
Cheers,
On 30/03/2020 20:21, Julien Grall wrote:
From: Julien Grall
Hi all,
This series is meant to solve the build issue reported by Dario when
using recent version of OCaml and -safe-string.
I took the opportunity to harden a bit
flight 149686 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149686/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Jan,
On 30/03/2020 08:38, Jan Beulich wrote:
Maybe some variation thereof:
- hvm_cr3_to_gfn()/hvm_gfn_to_cr3(): Handle the CR3 for HVM guest
- {pv,compat}_mfn_to_cr3()/{pv,compat}_cr3_to_mfn(): Handle the CR3 for PV
guest
- cr3_to_mfn()/mfn_to_cr3(): To handle the host cr3
? This is
> On 16. Apr 2020, at 12:18, Andrew Cooper wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> The
> On 16. Apr 2020, at 12:32, Andrew Cooper wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> From:
> On 16. Apr 2020, at 12:36, Andrew Cooper wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> @@ -2
The special AMD behavior of leaving SS mostly alone wasn't really
complete: We need to adjust CPL aka SS.DPL.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6022,6 +6022,8 @@ x86_emulate(
/* There's explicit
On 16.04.2020 13:24, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
> data to guest handle marked const.
>
> Thankfully, no users of the helper will do that. Rather than hoping this
> can be caught during review, harden copy_
> -Original Message-
> From: Jan Beulich
> Sent: 14 April 2020 12:45
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monne
> ; Paul Durrant
> Subject: [PATCH v6 03/10] x86emul: support MOVDIR{I,64B} insns
>
> Introduce a new blk() hook, paralleling the r
Using the standard -m elf_x86_64 for 64-bit mini-os results in the
first section (.text) to start only at offset 2MB in the binary file.
Using -m elf_i386 avoids that problem without any visible disadvantage.
Signed-off-by: Juergen Gross
---
arch/x86/arch.mk | 2 ++
1 file changed, 2 insertions
Limiting the number of event channels to 1024 is fine for 32-bit
builds, but not for 64-bit ones. This might be a problem when using
Xenstore-stubdom as the number of domains which can be supported is
then limited to a little bit more than 1000.
So raise the number of event channels to 4096 in 64-
Provide a mini-os binary stripped from debug information in order to
have a smaller resulting kernel file. The binary with debug
information is kept with the suffix "-debug".
Signed-off-by: Juergen Gross
---
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile
Juergen Gross, le jeu. 16 avril 2020 14:27:00 +0200, a ecrit:
> Limiting the number of event channels to 1024 is fine for 32-bit
> builds, but not for 64-bit ones. This might be a problem when using
> Xenstore-stubdom as the number of domains which can be supported is
> then limited to a little bit
Juergen Gross, le jeu. 16 avril 2020 14:27:48 +0200, a ecrit:
> Provide a mini-os binary stripped from debug information in order to
> have a smaller resulting kernel file. The binary with debug
> information is kept with the suffix "-debug".
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel
On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > We want to use the same rune to build mm/*/guest_*.o as the one use to
> > build every other *.o object. The consequence it that file symbols that
> > the program ./symbols prefer changes w
Juergen Gross, le jeu. 16 avril 2020 14:27:31 +0200, a ecrit:
> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
> first section (.text) to start only at offset 2MB in the binary file.
? I'm not seeing this on my system:
0 .text 0001933a 00
On Wed, Apr 08, 2020 at 03:02:21PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > Use if_changed for building all guest_%.o objects, and make use of
> > command that already exist.
> >
> > This patch make a change to the way guest_%.o files are built, and now
> > run th
On 16.04.20 14:46, Samuel Thibault wrote:
Juergen Gross, le jeu. 16 avril 2020 14:27:31 +0200, a ecrit:
Using the standard -m elf_x86_64 for 64-bit mini-os results in the
first section (.text) to start only at offset 2MB in the binary file.
? I'm not seeing this on my system:
0 .text
On Wed, Apr 08, 2020 at 03:28:06PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:31, Anthony PERARD wrote:
> > Both script mkflask.sh and mkaccess_vector.sh generates multiple
> > files. Exploits the 'multi-target pattern rule' trick to call each
> > scripts only once.
>
> Isn't this a general fix,
On Wed, Apr 08, 2020 at 03:53:01PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:31, Anthony PERARD wrote:
> > Improvement are:
> > - give the path to xlat.lst as argument
> > - include `grep -v` in compat-build-source.py script, we don't need to
> > write this in several scripted language.
> > -
Jürgen Groß, le jeu. 16 avril 2020 14:58:34 +0200, a ecrit:
> Specifically, 64bit emulation appears to include "align primary
> sections to 2M so your OS can make better use of superpages even when
> mmap()ing", with no way I can spot to override this in the linker
> file."
Ok, I see, I had in
flight 149667 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149667/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 149648
Tests which did not succeed
Using the standard -m elf_x86_64 for 64-bit mini-os results in the
first section (.text) to start only at offset 2MB in the binary file.
Quoting Andrew Cooper on that topic:
Specifically, 64bit emulation appears to include "align primary
sections to 2M so your OS can make better use of superp
The changes in the OCaml C stubs look good to me. They don't really touch the
interface but are mostly concerned with types on the C side by adding casts,
const, and so on. The extended error handling is an improvement.
-- Christian
--
Acked-by: Christian Lindig
On Thu, Apr 16, 2020 at 02:30:02PM +0200, Samuel Thibault wrote:
> Juergen Gross, le jeu. 16 avril 2020 14:27:48 +0200, a ecrit:
> > Provide a mini-os binary stripped from debug information in order to
> > have a smaller resulting kernel file. The binary with debug
> > information is kept with the
On Thu, Apr 16, 2020 at 03:17:15PM +0200, Juergen Gross wrote:
> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
> first section (.text) to start only at offset 2MB in the binary file.
>
> Quoting Andrew Cooper on that topic:
>
> Specifically, 64bit emulation appears to inclu
On Thu, Apr 16, 2020 at 02:29:18PM +0200, Samuel Thibault wrote:
> Juergen Gross, le jeu. 16 avril 2020 14:27:00 +0200, a ecrit:
> > Limiting the number of event channels to 1024 is fine for 32-bit
> > builds, but not for 64-bit ones. This might be a problem when using
> > Xenstore-stubdom as the n
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
Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't req
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Hello,
This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.
Thanks, Roger.
Roger Pau Monne (3):
x86/tlb: introduce a flush HVM ASIDs flag
x86/tlb: allow disabling the TLB clock
x86/tlb: use X
On Wed, Apr 08, 2020 at 03:56:02PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:31, Anthony PERARD wrote:
> > Replace a mix of shell script and python script by all python script.
> >
> > Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the
> > linemarkers generated by the preprocessor.
On 16.04.2020 14:44, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> We want to use the same rune to build mm/*/guest_*.o as the one use to
>>> build every other *.o object. The consequence it that file symbols t
On 16.04.2020 14:57, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:02:21PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:30, Anthony PERARD wrote:
>>> Use if_changed for building all guest_%.o objects, and make use of
>>> command that already exist.
>>>
>>> This patch make a change to the way
On 16.04.2020 15:02, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:28:06PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:31, Anthony PERARD wrote:
>>> Both script mkflask.sh and mkaccess_vector.sh generates multiple
>>> files. Exploits the 'multi-target pattern rule' trick to call each
>>> scr
On 16.04.2020 16:17, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 03:56:02PM +0200, Jan Beulich wrote:
>> On 31.03.2020 12:31, Anthony PERARD wrote:
>>> Replace a mix of shell script and python script by all python script.
>>>
>>> Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the
>>
flight 149676 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149676/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-5 51 xtf/test-hvm64-lbr-tsx-vmentry fail in 149650 pass
in 149676
test-amd64-amd64-xl
On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
> On 16.04.2020 14:44, Anthony PERARD wrote:
> > On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
> >> On 31.03.2020 12:30, Anthony PERARD wrote:
> >>> We want to use the same rune to build mm/*/guest_*.o as the one use to
> >
flight 149688 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149688/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Repeatedly looking at varying parts of this code has lead to
me accumulating a few adjustments.
1: fold p2m_mem_paging_prep()'s main if()-s
2: correct p2m_mem_paging_prep()'s error handling
3: use guest handle for XENMEM_paging_op_prep
4: add minimal lock order enforcement to p2m_mem_paging_prep()
The condition of the second can be true only if the condition of the
first was met; the second half of the condition of the second then also
is redundant with an earlier check. Combine them, drop a pointless
local variable, and re-flow the affected gdprintk().
Signed-off-by: Jan Beulich
--- a/xe
Communicating errors from p2m_set_entry() to the caller is not enough:
Neither the M2P nor the stats updates should occur in such a case.
Instead the allocated page needs to be freed again; for cleanliness
reasons also properly take into account _PGC_allocated there.
Signed-off-by: Jan Beulich
-
While it should have been this way from the beginning, not doing so will
become an actual problem with PVH Dom0. The interface change is binary
compatible, but requires tools side producers to be re-built.
Drop the bogus/unnecessary page alignment restriction on the input
buffer at the same time.
While full checking is impossible (as the lock is being acquired/
released down the call tree), perform at least a lock level check.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1813,6 +1813,7 @@ int p2m_mem_paging_prep(struct domain *d
goto
Do a little bit of style adjustment along the way, and drop the
"p2m_mem_paging_" prefixes from the now static functions.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,6 +25,421 @@
#include
#include
+#include "mm-locks.h"
+
+/*
+ *
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -278,7 +278,7 @@ static int set_mem_type(struct domain *d
if ( p2m_is_paging(t) )
{
put_gfn(d, pfn);
-p2m_mem_paging_populate(d, pfn);
+p2m_mem_paging_popul
On Wed, 2020-04-15 at 11:08 +0200, Jürgen Groß wrote:
> On 27.03.20 20:30, Jeff Kubascik wrote:
> > For each UNIT, sched_set_affinity is called before unit->priv is
> > updated
> > to the new cpupool private UNIT data structure. The issue is
> > sched_set_affinity will call the adjust_affinity meth
On Thu, 2020-04-09 at 14:50 +0200, Jürgen Groß wrote:
> On 09.04.20 11:41, Sergey Dyasli wrote:
> > In core-scheduling mode, Xen might crash when entering ACPI S5
> > state.
> > This happens in sched_slave() during is_idle_unit(next) check
> > because
> > next->vcpu_list is stale and points to an a
On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core
> scheduling job"):
> > Run a simple core scheduling tests on a host that has SMT support.
> > This is only enabled for Xen >= 4.13.
> ...
> > + # Core-scheduling tests are
On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core
> > scheduling job"):
> > > Run a simple core scheduling tests on a host that has SMT support.
> > > This
On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
> Currently it might be not obvious which scheduling mode is being used
> by the scheduler. Alleviate this by printing additional information
> about the selected granularity.
>
I like the idea. However, I don't like how verbose and long that
On Thu, 2020-04-16 at 11:25 +0200, Jürgen Groß wrote:
> On 16.04.20 11:20, Sergey Dyasli wrote:
> > On 16/04/2020 09:57, Jürgen Groß wrote:
> > >
> > > The xen commandline ins part of the boot messages and is
> > > contained
> > > in the "xl info" output.
> >
> > It's true that you can see "sched
On Thu, 2020-04-16 at 18:36 +0200, Roger Pau Monné wrote:
> On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> > On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> > >
> > > This seems fine as far as it goes, but all it does is check that
> > > things still work if sched-gran=c
Roger Pau Monne writes ("Re: [PATCH OSSTEST 2/2] make-flight: add a core
scheduling job"):
> On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> > Yep, and that's enough for enabling and starting using ore-scheduling.
> > So, doing like this, core-scheduling should get the same amoun
Dario Faggioli writes ("Re: [PATCH OSSTEST 2/2] make-flight: add a core
scheduling job"):
> Ok, sure. Maybe it would make sense to add just another one for Credit,
> sooner rather than later, as I guess there may be people wanting to
> continue use Credit, but they may want to try it with core-sch
flight 149678 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149678/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 149659 pass in 149678
test-amd64-amd64-examine4 mem
flight 149684 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149684/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On Wed, 15 Apr 2020, Jan Beulich wrote:
> On 15.04.2020 11:56, George Dunlap wrote:
> >
> >
> >> On Apr 15, 2020, at 10:49 AM, Julien Grall wrote:
> >>
> >>
> >>
> >> On 15/04/2020 10:43, George Dunlap wrote:
> On Apr 15, 2020, at 7:23 AM, Jan Beulich wrote:
>
> On 14.04.2020 18:
On Wed, 15 Apr 2020, Jason Yan wrote:
> Fix the following sparse warning:
>
> arch/arm64/xen/../../arm/xen/enlighten.c:39:19: warning: symbol
> '_xen_start_info' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Reviewed-by: Stefano Stabellini
> --
flight 149685 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149685/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 06033f5abad3815e8d80de22c97ba38a05017262
baseline version:
ovmf 8c654bb3ec0b5232dec2b
flight 149681 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149681/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 149660
test-amd64-amd64-xl-qemuu-win7-amd6
flight 149689 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149689/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 149667
test-armhf-armhf-libvirt-raw 13 save
On 16.04.2020 23:14, Stefano Stabellini wrote:
> On Wed, 15 Apr 2020, Jan Beulich wrote:
>> On 15.04.2020 11:56, George Dunlap wrote:
>>>
>>>
On Apr 15, 2020, at 10:49 AM, Julien Grall wrote:
On 15/04/2020 10:43, George Dunlap wrote:
>> On Apr 15, 2020, at 7:23 AM, Jan
87 matches
Mail list logo
