On 2/5/20 8:59 PM, Santucco wrote:
> Hello,
> Ok, I commented out the memcpy call and run the test.
> displ_be hasn’t crached, I have seen FLIP events in the log.
> But there hasn’t been the black screen, just a blink effect every
> couple of seconds.
> Logs are attached.
Ok, so I believe that fr
AFAICT these patches have the necessary A-b/R-b-s, or are there some missing
that I need to chase?
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 03 February 2020 10:57
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ;
On 05.02.2020 18:45, Julien Grall wrote:
> On 05/02/2020 16:47, Jan Beulich wrote:
>> On 05.02.2020 17:25, Xia, Hongyan wrote:
>>> Ping.
>>
>> Sorry, there's just too much else also needing attention. I'm
>> doing what I can review-wise, and I assume some others do so,
>> too. You're very welcome t
flight 146755 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146755/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 06.02.2020 09:28, Durrant, Paul wrote:
> AFAICT these patches have the necessary A-b/R-b-s, or are there some missing
> that I need to chase?
According to my records ...
>> -Original Message-
>> From: Paul Durrant
>> Sent: 03 February 2020 10:57
>>
>> Paul Durrant (4):
>> x86 / vmx
On 05.02.2020 19:02, Wei Liu wrote:
> There is no need for every CPU to set a guest property.
>
Suggested-by: Roger?
> Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenprojec
> -Original Message-
> From: Jan Beulich
> Sent: 06 February 2020 08:46
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Rzeszutek Wilk ; Andrew
> Cooper ; Ian Jackson
> ; George Dunlap ; Tim
> Deegan ; Jun Nakajima ; Volod
flight 146753 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 146121
test-amd64-i386-qemut
On Wed, Feb 05, 2020 at 06:02:24PM +, Wei Liu wrote:
> There is no need for every CPU to set a guest property.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
I will send a patch shortly to introduce an IS_BSP macro, as it would
make the code clearer IMO.
Thanks, Roger.
_
On 05.02.2020 17:50, Andrew Cooper wrote:
> --- a/tools/libxc/xc_sr_restore_x86_hvm.c
> +++ b/tools/libxc/xc_sr_restore_x86_hvm.c
> @@ -72,6 +72,16 @@ static int handle_hvm_params(struct xc_sr_context *ctx,
> case HVM_PARAM_BUFIOREQ_PFN:
> xc_clear_domain_page(xch, ctx->domid,
flight 146754 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
Hi,
On 03/02/2020 10:56, Paul Durrant wrote:
This patch adds a new domain_tot_pages() inline helper function into
sched.h, which will be needed by a subsequent patch.
No functional change.
NOTE: While modifying the comment for 'tot_pages' in sched.h this patch
makes some cosmetic fixes
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usually get:
(it's easily reproducible)
(XEN) [ 342.528305] livepatch: lp: CPU8 - IPIing the other 15 CPUs
(XEN) [ 34
Hi,
I am sorry to jump that late in the conversation.
On 03/02/2020 10:56, Paul Durrant wrote:
-if ( unlikely(domain_adjust_tot_pages(d, 1 << order) == (1 << order)) )
+if ( !(memflags & MEMF_no_refcount) &&
+ unlikely(domain_adjust_tot_pages(d, 1 << order) == (1 << order
> -Original Message-
> From: Julien Grall
> Sent: 06 February 2020 10:04
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap ;
> Ian Jackson ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu ; Volodymyr Babchuk ; Roger
> Pau Mon
flight 146756 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146756/
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-arm64-libvirt
From: Julien Grall
At the moment, assign_pages() on the page to be inuse (PGC_state_inuse)
and the state value to be 0.
However, the code may race with the page offlining code (see
offline_page()). Depending on the ordering, the page may be in offlining
state (PGC_state_offlining) before it is a
> -Original Message-
> From: Julien Grall
> Sent: 06 February 2020 10:39
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Durrant, Paul ; Grall, Julien
>
> Subject: [PATCH v2] xen/mm: Avoid assuming the page is inuse in
> assign_pages()
>
> From: Julien Grall
>
> At the momen
On 06/02/2020 09:57, Jürgen Groß wrote:
> On 05.02.20 17:03, Sergey Dyasli wrote:
>> Hello,
>>
>> I'm currently investigating a Live-Patch application failure in core-
>> scheduling mode and this is an example of what I usually get:
>> (it's easily reproducible)
>>
>> (XEN) [ 342.528305] live
flight 146758 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On Mon, Jan 27, 2020 at 07:11:10PM +0100, Roger Pau Monne wrote:
> 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 w
Hi Paul,
On 06/02/2020 10:52, Durrant, Paul wrote:
-Original Message-
From: Julien Grall
Sent: 06 February 2020 10:39
To: xen-devel@lists.xenproject.org
Cc: jul...@xen.org; Durrant, Paul ; Grall, Julien
Subject: [PATCH v2] xen/mm: Avoid assuming the page is inuse in
assign_pages()
Fro
On Mon, Jan 27, 2020 at 07:11:12PM +0100, Roger Pau Monne wrote:
> The current implementation of the hypervisor assisted flush for HAP is
> extremely inefficient.
>
> First of all there's no need to call paging_update_cr3, as the only
> relevant part of that function when doing a flush is the ASID
On 06/02/2020 09:28, Jan Beulich wrote:
> On 05.02.2020 17:50, Andrew Cooper wrote:
>> --- a/tools/libxc/xc_sr_restore_x86_hvm.c
>> +++ b/tools/libxc/xc_sr_restore_x86_hvm.c
>> @@ -72,6 +72,16 @@ static int handle_hvm_params(struct xc_sr_context *ctx,
>> case HVM_PARAM_BUFIOREQ_PFN:
>>
On Wed, Feb 05, 2020 at 11:45:39AM +, Wei Liu wrote:
> On Wed, Feb 05, 2020 at 09:12:50AM +0100, Jan Beulich wrote:
> > On 04.02.2020 18:19, Wei Liu wrote:
> > > On Tue, Feb 04, 2020 at 06:07:00PM +0100, Jan Beulich wrote:
> > >> On 04.02.2020 17:55, Wei Liu wrote:
> > >>> Signed-off-by: Wei Li
On 06.02.2020 12:32, Andrew Cooper wrote:
> On 06/02/2020 09:28, Jan Beulich wrote:
>> On 05.02.2020 17:50, Andrew Cooper wrote:
>>> --- a/xen/include/public/hvm/params.h
>>> +++ b/xen/include/public/hvm/params.h
>>> @@ -86,7 +86,7 @@
>>> #define HVM_PARAM_STORE_PFN1
>>> #define HVM_PARAM_STO
On 06.02.2020 12:34, Wei Liu wrote:
> On Wed, Feb 05, 2020 at 11:45:39AM +, Wei Liu wrote:
>> On Wed, Feb 05, 2020 at 09:12:50AM +0100, Jan Beulich wrote:
>>> On 04.02.2020 18:19, Wei Liu wrote:
On Tue, Feb 04, 2020 at 06:07:00PM +0100, Jan Beulich wrote:
> On 04.02.2020 17:55, Wei Liu
On 06.02.2020 11:12, Durrant, Paul wrote:
>> From: Julien Grall
>> Sent: 06 February 2020 10:04
>>
>> On 03/02/2020 10:56, Paul Durrant wrote:
>>> @@ -2332,11 +2350,23 @@ struct page_info *alloc_domheap_pages(
>>> memflags, d)) == NULL)) )
>>>return
> -Original Message-
> From: Julien Grall
> Sent: 06 February 2020 11:17
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Grall, Julien
> Subject: Re: [PATCH v2] xen/mm: Avoid assuming the page is inuse in
> assign_pages()
>
> Hi Paul,
>
> On 06/02/2020 10:52, Durrant, Paul wr
On 23.01.20 09:55, Juergen Gross wrote:
Currently the memory for each run-queue of the credit2 scheduler is
allocated at the scheduler's init function: for each cpu in the system
a struct csched2_runqueue_data is being allocated, even if the
current scheduler only handles one physical cpu or is c
On Thu, Feb 06, 2020 at 12:38:37PM +0100, Jan Beulich wrote:
> On 06.02.2020 12:34, Wei Liu wrote:
> > On Wed, Feb 05, 2020 at 11:45:39AM +, Wei Liu wrote:
> >> On Wed, Feb 05, 2020 at 09:12:50AM +0100, Jan Beulich wrote:
> >>> On 04.02.2020 18:19, Wei Liu wrote:
> On Tue, Feb 04, 2020 at
On 2/3/20 4:58 PM, Julien Grall wrote:
> From: Julien Grall
>
> It is not entirely clear why the slot 0 of each p2m should be populated
> with empty page-tables. The commit introducing it 759af8e3800 "[HVM]
> Fix 64-bit HVM domain creation." does not contain meaningful
> explanation except that i
Change the format string to use "[,]" and subtract 1 from the end.
Signed-off-by: Wei Liu
---
xen/arch/x86/e820.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 160f029edd..c9dc52c768 100644
--- a/xen/arch/x86/e820.c
+++ b/
On 06/02/2020 11:37, Jan Beulich wrote:
> On 06.02.2020 12:32, Andrew Cooper wrote:
>> On 06/02/2020 09:28, Jan Beulich wrote:
>>> On 05.02.2020 17:50, Andrew Cooper wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -86,7 +86,7 @@
#define HVM
flight 146759 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146759/
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
On 06.02.2020 13:10, Wei Liu wrote:
> Change the format string to use "[,]" and subtract 1 from the end.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
On 06.02.2020 12:44, Durrant, Paul wrote:
>> -Original Message-
>> From: Julien Grall
>> Sent: 06 February 2020 11:17
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Grall, Julien
>> Subject: Re: [PATCH v2] xen/mm: Avoid assuming the page is inuse in
>> assign_pages()
>>
>> H
On Mon, Jan 27, 2020 at 07:11:13PM +0100, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest TLB flush, which is
> an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
>
> This was previously unconditionally done in each pre_flush call, but
> that's not req
On 06.02.2020 11:38, Julien Grall wrote:
> However, the code may race with the page offlining code (see
> offline_page()). Depending on the ordering, the page may be in offlining
> state (PGC_state_offlining) before it is assigned to a domain.
>
> On debug build, this may result to hit the assert
1: check all of an RMRR for being E820-reserved
2: adjust logging of RMRRs
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
The local xc_hvm_param_deprecated_check() in libxc tries to guess Xen's
behaviour for the MEMORY_EVENT params, but is wrong for the get side, where
Xen would return 0 (which is also a bug). Delete the helper.
In Xen, perform the checks in hvm_allow_set_param(), rather than
hvm_set_param(), and ac
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 31 January 2020 16:43
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu ; Paul Durrant
> Subject: [Xen-devel] [PATCH v4 3/7] x86/HVM: introduce "curr" into
> hv
Consistently use [,] range representation, shrink leading double blanks
to a single one, and slightly adjust text in some cases.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -561,7 +561,7 @@ static int register_one_rmrr(struct ac
On Mon, Jan 27, 2020 at 07:11:14PM +0100, Roger Pau Monne wrote:
> 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
> u
Checking just the first and last page is not sufficient (and redundant
for single-page regions). As we don't need to care about IA64 anymore,
use an x86-specific function to get this done without looping over each
individual page.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/dmar
On 06.02.2020 14:26, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 31 January 2020 16:43
>> To: xen-devel@lists.xenproject.org
>> Cc: George Dunlap ; Andrew Cooper
>> ; Roger Pau Monné ; Wei
>> Liu ; Paul Durrant
>> Subject: [Xen-devel]
On 06.02.2020 14:24, Andrew Cooper wrote:
> The local xc_hvm_param_deprecated_check() in libxc tries to guess Xen's
> behaviour for the MEMORY_EVENT params, but is wrong for the get side, where
> Xen would return 0 (which is also a bug). Delete the helper.
>
> In Xen, perform the checks in hvm_al
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 31 January 2020 16:46
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Andrew Cooper
> ; Roger Pau Monné ; Wei
> Liu ; Paul Durrant
> Subject: [Xen-devel] [PATCH v4 7/7] x86/HVM: reduce scope of pfec in
>
On Thu, Feb 06, 2020 at 01:31:34PM +, Wei Liu wrote:
> On Mon, Jan 27, 2020 at 07:11:14PM +0100, Roger Pau Monne wrote:
> > 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
On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
> 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 shi
On 06/02/2020 12:57, Jan Beulich wrote:
> On 06.02.2020 12:44, Durrant, Paul wrote:
>>> -Original Message-
>>> From: Julien Grall
>>> Sent: 06 February 2020 11:17
>>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>>> Cc: Grall, Julien
>>> Subject: Re: [PATCH v2] xen/mm: Avoid assumin
On 06/02/2020 11:05, Sergey Dyasli wrote:
> On 06/02/2020 09:57, Jürgen Groß wrote:
>> On 05.02.20 17:03, Sergey Dyasli wrote:
>>> Hello,
>>>
>>> I'm currently investigating a Live-Patch application failure in core-
>>> scheduling mode and this is an example of what I usually get:
>>> (it's easily
On Thu, Feb 6, 2020 at 6:24 AM Andrew Cooper wrote:
>
> The local xc_hvm_param_deprecated_check() in libxc tries to guess Xen's
> behaviour for the MEMORY_EVENT params, but is wrong for the get side, where
> Xen would return 0 (which is also a bug). Delete the helper.
>
> In Xen, perform the chec
On Thu, Feb 06, 2020 at 01:49:35PM +, Wei Liu wrote:
> On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
> > 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
On 05/02/2020 16:50, Andrew Cooper wrote:
These have no callers, and the underlying infrastructure is about to be
rewritten completely.
Signed-off-by: Andrew Cooper
---
CC: Christian Lindig
---
tools/ocaml/libs/xc/xenctrl.ml | 7 -
tools/ocaml/libs/xc/xenctrl.mli | 7 -
On 06/02/2020 11:43, Jan Beulich wrote:
On 06.02.2020 11:12, Durrant, Paul wrote:
From: Julien Grall
Sent: 06 February 2020 10:04
On 03/02/2020 10:56, Paul Durrant wrote:
@@ -2332,11 +2350,23 @@ struct page_info *alloc_domheap_pages(
memflags, d)) == NUL
On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020 11:05, Sergey Dyasli wrote:
On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usual
On 06.02.2020 15:09, Roger Pau Monné wrote:
> On Thu, Feb 06, 2020 at 01:49:35PM +, Wei Liu wrote:
>> On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
>>> Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
>>> This greatly increases the performance of TLB flush
flight 146764 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
PTE flags, for now at least, get stored in "unsigned int". Hence there's
no need to widen the values to "unsigned long" before processing them.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -796,7 +796,7 @@ extern void audit_p2m(struct domain *d,
Both callers request the host P2M's default access, which can as well be
done inside the function. While touching this anyway, make the "gfn"
parameter type-safe as well.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3037,9 +3037,8 @@ static int
The field looks to have been bogusly added by the patch introducing the
struct (431685e8deb6 "VT-d: add command line option for extra rmrrs").
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -839,7 +839,6 @@ out:
/* RMRR units deri
On Thu, Feb 06, 2020 at 03:46:56PM +0100, Jan Beulich wrote:
> On 06.02.2020 15:09, Roger Pau Monné wrote:
> > On Thu, Feb 06, 2020 at 01:49:35PM +, Wei Liu wrote:
> >> On Mon, Jan 27, 2020 at 07:11:15PM +0100, Roger Pau Monne wrote:
> >>> Use Xen's L0 HVMOP_flush_tlbs hypercall in order to per
From: Julien Grall
There is an implicit padding of 2 bytes in struct xen_hvm_param between
the field domid and index. Make it explicit by introduce a padding
field. This can also serve as documentation.
Note that I don't think we can mandate it to be zero because a guest may
not have initialized
On 06.02.2020 16:41, Julien Grall wrote:
> From: Julien Grall
>
> There is an implicit padding of 2 bytes in struct xen_hvm_param between
> the field domid and index. Make it explicit by introduce a padding
> field. This can also serve as documentation.
>
> Note that I don't think we can mandate
On Thu, Feb 06, 2020 at 04:19:14PM +0100, Jan Beulich wrote:
> PTE flags, for now at least, get stored in "unsigned int". Hence there's
> no need to widen the values to "unsigned long" before processing them.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
Hi Jan,
On 06/02/2020 15:52, Jan Beulich wrote:
On 06.02.2020 16:41, Julien Grall wrote:
From: Julien Grall
There is an implicit padding of 2 bytes in struct xen_hvm_param between
the field domid and index. Make it explicit by introduce a padding
field. This can also serve as documentation.
On Thu, Feb 06, 2020 at 04:20:02PM +0100, Jan Beulich wrote:
> Both callers request the host P2M's default access, which can as well be
> done inside the function. While touching this anyway, make the "gfn"
> parameter type-safe as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monn
On Thu, Feb 06, 2020 at 03:41:18PM +, Julien Grall wrote:
> From: Julien Grall
>
> There is an implicit padding of 2 bytes in struct xen_hvm_param between
> the field domid and index. Make it explicit by introduce a padding
> field. This can also serve as documentation.
>
> Note that I don't
The purpose of the change-log is to be a human-readable list of notable
changes and, as such, additions to it are likely of interest to the
community manager in preparing blog entries, release summaries, etc.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
C
On Thu, Feb 06, 2020 at 04:48:10PM +, Paul Durrant wrote:
> The purpose of the change-log is to be a human-readable list of notable
> changes and, as such, additions to it are likely of interest to the
> community manager in preparing blog entries, release summaries, etc.
>
> Signed-off-by: Pa
flight 146765 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146765/
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
On Thu, Feb 6, 2020 at 8:33 AM Jan Beulich wrote:
>
> Consistently use [,] range representation, shrink leading double blanks
> to a single one, and slightly adjust text in some cases.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/
flight 146757 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146757/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 146751 pass in 146757
test-amd64-i386-qemut-rhel6hvm-a
Rewrite the mapcache to be purely per-vCPU instead of partially per-vcpu
and partially per-domain.
The existing mapcache implementation keeps per-vcpu hash tables for
caching, but also creates a per-domain region which is shared by all
vcpus and protected by a per-domain lock. When the vcpu count
flight 146766 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146767 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146767/
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
flight 146760 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146760/
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.
146121
test-amd64-i386-xl
flight 146762 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146762/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
flight 146770 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146773 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146769 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 146757
test-amd64-i386-pa
flight 146772 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
flight 146774 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
When dumping the run queue information add some more data regarding
current and (if known) previous vcpu for each physical cpu.
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/xen/common/sched/core.
flight 146771 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146771/
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.
146121
test-amd64-i386-xl
flight 146775 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146775/
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
87 matches
Mail list logo
