flight 148672 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148672/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 01ce872739d2f0cd3a8917be2180381db5f0391e
baseline version:
ovmf
flight 148656 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148656/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 148611
On Fri, 2020-02-21 at 18:06 +0100, Jan Beulich wrote:
> On 01.02.2020 01:33, David Woodhouse wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -678,6 +678,92 @@ static unsigned int __init copy_bios_e820(struct
> > e820entry *map, unsigned int li
> > return n;
> > }
pygrub in xen-4.13.0 with python 3.8.2 fails with the error
Traceback (most recent call last):
File "/usr/libexec/xen/bin/pygrub", line 21, in
import xen.lowlevel.xc
SystemError: bad call flags
This patch fixes mismatches in tools/python/xen/lowlevel/xc/xc.c
between the flag bits defined
On Thu, 2020-02-20 at 12:59 +0100, Jan Beulich wrote:
> On 07.02.2020 19:04, David Woodhouse wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -488,7 +488,8 @@ void share_xen_page_with_guest(struct page_info *page,
> > struct domain *d,
> >
> > page_set_owner(page, d);
On Thu, 2020-02-20 at 12:10 +0100, Jan Beulich wrote:
> On 07.02.2020 16:57, David Woodhouse wrote:
> > @@ -1145,16 +1145,19 @@ static int reserve_offlined_page(struct
> > page_info *head)
> >
> > for ( cur_head = head; cur_head < head + ( 1UL << head_order);
> > cur_head++ )
> > {
> >
On Fri, 2020-02-07 at 20:27 +, Julien Grall wrote:
> > +switch ( x & PGC_state )
> > {
> > -nx &= ~PGC_state;
> > -nx |= (((x & PGC_state) == PGC_state_free)
> > - ? PGC_state_offlined : PGC_state_offlining);
> > -}
> > +
flight 148675 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148675/
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
flight 148648 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Tests which
On Wed, Mar 04, 2020 at 04:00:52PM +0100, Jan Beulich wrote:
> On 26.02.2020 12:33, Anthony PERARD wrote:
> > @@ -113,6 +115,64 @@ $(KCONFIG_CONFIG):
> > +AFLAGS += -D__ASSEMBLY__
> > +
> > +CFLAGS += $(CFLAGS-y)
>
> I can't seem to be able to spot a similar line for AFLAGS.
I didn't add any
On Thu, Feb 27, 2020 at 12:05:04PM +0100, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 11:33:47AM +, Anthony PERARD wrote:
> > +ifeq ($(CONFIG_DEBUG),y)
> > +CFLAGS += -O1
> > +else
> > +CFLAGS += -O2
> > +endif
>
> Long term we might want to make the optimization level selectable in
>
On Tue, 17 Mar 2020, Julien Grall wrote:
> Hi,
>
> On 13/03/2020 23:14, Stefano Stabellini wrote:
> > On Fri, 13 Mar 2020, Stefano Stabellini wrote:
> > > On Mon, 9 Mar 2020, Anthony PERARD wrote:
> > > > At the moment, early printk can only be configured on the make command
> > > > line. It is
Paul Durrant writes ("RE: [PATCH v2 2/2] libxl: make creation of xenstore
'suspend event channel' node optional..."):
> So, naming-wise... 'xend_compat', or is that too vague?
> > - the ~/device writeability is controlled by the same compat flag,
> > with corresponding update to the docs
On Tue, 2020-03-17 at 16:59 +, Ian Jackson wrote:
> David Woodhouse writes ("Re: [PATCH] Add -MP to CFLAGS along with -MMD."):
> > On Tue, 2020-03-17 at 15:52 +0100, Jan Beulich wrote:
> > > On 17.03.2020 15:34, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
> > > > This causes
> -Original Message-
> From: Ian Jackson
> Sent: 17 March 2020 16:51
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Andrew Cooper
> ;
> George Dunlap ; Jan Beulich ;
> Julien Grall
> ; Stefano Stabellini ; Anthony Perard
>
> Subject: Re: [PATCH v2 2/2] libxl: make
David Woodhouse writes ("Re: [PATCH] Add -MP to CFLAGS along with -MMD."):
> On Tue, 2020-03-17 at 15:52 +0100, Jan Beulich wrote:
> > On 17.03.2020 15:34, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > This causes gcc (yes, and clang) to emit phony targets for each
> > >
On Tue, Mar 17, 2020 at 10:35 AM Jan Beulich wrote:
>
> On 17.03.2020 17:23, Tamas K Lengyel wrote:
> > On Tue, Mar 17, 2020 at 10:02 AM Jan Beulich wrote:
> >> On 28.02.2020 19:40, Tamas K Lengyel wrote:
> >>> @@ -588,7 +594,8 @@ struct page_info *p2m_get_page_from_gfn(
> >>>
flight 148671 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148671/
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
pdurr...@amzn.com writes ("[PATCH v2 2/2] libxl: make creation of xenstore
'suspend event channel' node optional..."):
> From: Paul Durrant
>
> ... and make the top level 'device' node in xenstore writable by the
> guest
Sorry for taking a long time to review this. Thanks for your
proposal.
On 17.03.2020 17:23, Tamas K Lengyel wrote:
> On Tue, Mar 17, 2020 at 10:02 AM Jan Beulich wrote:
>> On 28.02.2020 19:40, Tamas K Lengyel wrote:
>>> @@ -588,7 +594,8 @@ struct page_info *p2m_get_page_from_gfn(
>>> return page;
>>>
>>> /* Error path: not a suitable GFN at all
On Tue, Mar 17, 2020 at 11:23 AM Jason Andryuk wrote:
>
> On 17.03.2020 15:08, Jan Beulich wrote:
> >On 17.03.2020 15:08, Jan Beulich wrote:
> >> On 17.03.2020 14:48, Jason Andryuk wrote:
> >>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
> >>> the HPET to provide a
On Tue, Mar 17, 2020 at 10:02 AM Jan Beulich wrote:
>
> On 28.02.2020 19:40, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -509,6 +509,12 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m,
> > unsigned long gfn_l,
> >
> > mfn =
On 28.02.2020 19:40, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -509,6 +509,12 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m,
> unsigned long gfn_l,
>
> mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order, NULL);
>
> +/* Check if we
On 13.03.2020 14:06, Juergen Gross wrote:
> Add a lock specific counter to rcu read locks in debug builds. This
> allows to test for matching lock/unlock calls.
>
> This will help to avoid cases like the one fixed by commit
> 98ed1f43cc2c89 where different rcu read locks were referenced in the
>
On 17.03.2020 15:08, Jan Beulich wrote:
>On 17.03.2020 15:08, Jan Beulich wrote:
>> On 17.03.2020 14:48, Jason Andryuk wrote:
>>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
>>> the HPET to provide a periodic timer in hpet_resume() on T0. When I
>>> actually got it
On 17/03/2020 13:06, Jan Beulich wrote:
On 10.03.2020 18:49, p...@xen.org wrote:
In auditing open-coded tests of PGC_xen_heap, I am unsure if offline_page()
needs to check for PGC_extra pages too.
"Extra" pages being the designated replacement for Xen heap ones,
I think it should. Then
> -Original Message-
> From: Jan Beulich
> Sent: 10 March 2020 14:19
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Varad Gautam' ; 'Julien
> Grall' ;
> 'Roger Pau Monné' ; 'Andrew Cooper'
>
> Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
>
On Tue, 2020-03-17 at 15:52 +0100, Jan Beulich wrote:
> On 17.03.2020 15:34, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > This causes gcc (yes, and clang) to emit phony targets for each dependency.
> >
> > This means that when a header file is deleted, the C files which *used*
> >
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 == _fatal
(the program will exit prior to the error_append_hint() or
error_prepend() call). Fix such cases.
If we want to
v10: (based-on "[PATCH 0/3] Minor error handling cleanups" including my 4/3 in
it)
02: Change some comments.
Do not chain check1 and check2 rules to rule1 to cover move
unusual cases to warn about.
Add positions to check1 rule.
Move check1 and check2 above rule1, otherwise our ___
Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal and error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information
Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
does corresponding changes in code (look for details in
include/qapi/error.h)
Usage example:
spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-file scripts/cocci-macro-file.h --in-place --no-show-diff \
> -Original Message-
> From: Jan Beulich
> Sent: 17 March 2020 13:14
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Stefano Stabellini
> ; Julien Grall ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk
> ; Wei
On 17.03.2020 15:47, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 17 March 2020 13:07
>>
>> On 10.03.2020 18:49, p...@xen.org wrote:
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -749,8 +749,9 @@
Hi Jan,
On 13/03/2020 07:32, Jan Beulich wrote:
The other day, in the context of what is now cf38b4926e2b ("xmalloc:
guard against integer overflow"), Andrew had suggested to look into
using gcc's __builtin_*_overflow(). The functions don't lend themselves
to be used there with the logic
Hi Jan,
On 13/03/2020 07:35, Jan Beulich wrote:
Along the lines of commit d0b3ab0a0f46 ("libfdt: Fix undefined behaviour
in fdt_offset_ptr()"), _fdt_splice() similarly may not use pointer
arithmetic to do overflow checks.
[upstream commit 73d6e9ecb4179b510408bc526240f829262df361]
On 17.03.2020 15:34, David Woodhouse wrote:
> From: David Woodhouse
>
> This causes gcc (yes, and clang) to emit phony targets for each dependency.
>
> This means that when a header file is deleted, the C files which *used*
> to include it will no longer stop building with bogus out-of-date
>
Hi Jan,
On 13/03/2020 07:35, Jan Beulich wrote:
From: David Gibson
Using pointer arithmetic to generate a pointer outside a known object is,
technically, undefined behaviour in C. Unfortunately, we were using that
in fdt_offset_ptr() to detect overflows.
To fix this we need to do our bounds
> -Original Message-
> From: Jan Beulich
> Sent: 17 March 2020 13:07
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Tamas K Lengyel
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau
> Monné ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Konrad Rzeszutek
> Wilk
On 17/03/2020 14:34, David Woodhouse wrote:
> From: David Woodhouse
>
> This causes gcc (yes, and clang) to emit phony targets for each dependency.
>
> This means that when a header file is deleted, the C files which *used*
> to include it will no longer stop building with bogus out-of-date
>
On 13.03.2020 14:06, Juergen Gross wrote:
> Xen's RCU implementation relies on no softirq handling taking place
> while being in a RCU critical section. Add ASSERT()s in debug builds
> in order to catch any violations.
>
> For that purpose modify rcu_read_[un]lock() to use a dedicated percpu
>
From: David Woodhouse
This causes gcc (yes, and clang) to emit phony targets for each dependency.
This means that when a header file is deleted, the C files which *used*
to include it will no longer stop building with bogus out-of-date
dependencies like this:
make[5]: *** No rule to make
On 13.03.2020 14:06, Juergen Gross wrote:
> Some keyhandlers are calling process_pending_softirqs() while holding
> a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
> activate rcu calls which should not happen inside a rcu_read_lock().
>
> For that purpose modify
On 17.03.2020 15:08, Jason Andryuk wrote:
> On Tue, Mar 17, 2020 at 9:48 AM Jason Andryuk wrote:
>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
>> the HPET to provide a periodic timer in hpet_resume() on T0. When I
>> actually got it programmed properly, it worked to
On 17.03.2020 15:08, Jan Beulich wrote:
> On 17.03.2020 14:48, Jason Andryuk wrote:
>> I got it to boot past "IO-APIC + timer doesn't work". I programmed
>> the HPET to provide a periodic timer in hpet_resume() on T0. When I
>> actually got it programmed properly, it worked to increment
>>
On 17.03.2020 14:48, Jason Andryuk wrote:
> On Wed, Mar 4, 2020 at 11:06 AM Jason Andryuk wrote:
>>
>> On Wed, Feb 19, 2020 at 3:25 AM Jan Beulich wrote:
>>>
>>> On 18.02.2020 22:45, Andrew Cooper wrote:
On 18/02/2020 18:43, Jason Andryuk wrote:
> On Mon, Feb 17, 2020, 8:22 PM Andrew
On Tue, Mar 17, 2020 at 9:48 AM Jason Andryuk wrote:
> I got it to boot past "IO-APIC + timer doesn't work". I programmed
> the HPET to provide a periodic timer in hpet_resume() on T0. When I
> actually got it programmed properly, it worked to increment
> pit0_ticks. I also made
On 13.03.2020 14:06, Juergen Gross wrote:
> @@ -143,51 +143,85 @@ static int qhimark = 1;
> static int qlowmark = 100;
> static int rsinterval = 1000;
>
> -struct rcu_barrier_data {
> -struct rcu_head head;
> -atomic_t *cpu_count;
> -};
> +/*
> + * rcu_barrier() handling:
> + *
14.03.2020 0:54, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
13.03.2020 18:42, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
12.03.2020 19:36, Markus Armbruster wrote:
I may have a second look tomorrow with fresher eyes, but let's get this
out now as is.
On Wed, Mar 4, 2020 at 11:06 AM Jason Andryuk wrote:
>
> On Wed, Feb 19, 2020 at 3:25 AM Jan Beulich wrote:
> >
> > On 18.02.2020 22:45, Andrew Cooper wrote:
> > > On 18/02/2020 18:43, Jason Andryuk wrote:
> > >> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper
> > >> wrote:
> > >>> On 17/02/2020
On 10.03.2020 18:49, p...@xen.org wrote:
> From: Paul Durrant
>
> Currently shared_info is a shared xenheap page but shared xenheap pages
> complicate future plans for live-update of Xen so it is desirable to,
> where possible, not use them [1]. This patch therefore converts shared_info
> into a
On 10.03.2020 18:49, p...@xen.org wrote:
> In auditing open-coded tests of PGC_xen_heap, I am unsure if offline_page()
> needs to check for PGC_extra pages too.
"Extra" pages being the designated replacement for Xen heap ones,
I think it should. Then again the earlier
if ( (owner =
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-win7-amd64
testid windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 148641 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
133580
Tests
flight 148651 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148651/
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 17/03/2020 10:24, Jan Beulich wrote:
> On 16.03.2020 22:47, Igor Druzhinin wrote:
>> args.preempted as meaningless here and doesn't show if the hypercall
>> was preempted before. Use start_extent instead which is correct.
>
> ... as long as the hypercall was invoked in a "normal" way.
>
>>
flight 148646 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148646/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 148176
test-amd64-amd64-xl-qemuu-ws16-amd64 17
17.03.2020 13:39, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
16.03.2020 11:21, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
On 14.03.2020 00:54, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
13.03.2020 18:42, Markus Armbruster wrote:
> -Original Message-
> From: Jan Beulich
> Sent: 17 March 2020 10:45
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
> ; 'George Dunlap'
> ; 'Ian Jackson' ;
> 'Julien Grall'
> ; 'Stefano Stabellini' ; 'Wei Liu'
> ; 'Roger Pau
> Monné'
> Subject: Re: [PATCH v6
On 16.03.2020 19:11, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 16 March 2020 16:53
>>
>> On 10.03.2020 18:49, p...@xen.org wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -2314,7 +2314,7 @@ int assign_pages(
>>>
flight 148637 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
Vladimir Sementsov-Ogievskiy writes:
> 16.03.2020 11:21, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> On 14.03.2020 00:54, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
> 13.03.2020 18:42, Markus Armbruster wrote:
>> Vladimir
On 16.03.2020 22:47, Igor Druzhinin wrote:
> args.preempted as meaningless here and doesn't show if the hypercall
> was preempted before. Use start_extent instead which is correct.
... as long as the hypercall was invoked in a "normal" way.
> Signed-off-by: Igor Druzhinin
> ---
> This fixes
On 16.03.2020 18:30, Hongyan Xia wrote:
> From: Hongyan Xia
>
> The allocation can just return NULL. Return an error value early instead
> of crashing later on.
Not very likely, and we'll be in bigger trouble in such a case, but
yes.
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
flight 148644 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148644/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a2c3bf1f2f991614ac97ddcf4b31742e4366c3a5
baseline version:
ovmf
16.03.2020 17:40, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
03.03.2020 11:01, Markus Armbruster wrote:
Hi Vladimir,
I've come to rather like your ERRP_AUTO_PROPAGATE() idea. What I
wouldn't like is a protracted conversion.
Once we're happy with PATCH 1-3, it's a matter
Hi,
On 13/03/2020 23:14, Stefano Stabellini wrote:
On Fri, 13 Mar 2020, Stefano Stabellini wrote:
On Mon, 9 Mar 2020, Anthony PERARD wrote:
At the moment, early printk can only be configured on the make command
line. It is not very handy because a user has to remove the option
everytime it is
16.03.2020 11:21, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
On 14.03.2020 00:54, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
13.03.2020 18:42, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
12.03.2020 19:36, Markus Armbruster wrote:
On Mon, 16 Mar 2020, Josh Poimboeuf wrote:
> On Mon, Mar 16, 2020 at 04:51:12PM +0100, Miroslav Benes wrote:
> > > diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
> > > index 6b88cdcbef8f..39afd88309cb 100644
> > > --- a/arch/x86/xen/smp_pv.c
> > > +++ b/arch/x86/xen/smp_pv.c
> > > @@
On Mon, 16 Mar 2020, Boris Ostrovsky wrote:
>
>
> On 3/12/20 10:20 AM, Miroslav Benes wrote:
> > --- a/arch/x86/xen/xen-head.S
> > +++ b/arch/x86/xen/xen-head.S
> > @@ -35,7 +35,7 @@ SYM_CODE_START(startup_xen)
> > rep __ASM_SIZE(stos)
> >
> > mov %_ASM_SI, xen_start_info
> > - mov
On Tue, Mar 17, 2020 at 06:22:55AM +, Tian, Kevin wrote:
> > From: Andrew Cooper
> > Sent: Saturday, March 14, 2020 12:03 AM
> >
> > On 12/03/2020 23:56, osstest service owner wrote:
> > > branch xen-unstable
> > > xenbranch xen-unstable
> > > job test-amd64-amd64-qemuu-nested-intel
> > >
flight 148636 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 16 guest-localmigrate fail REGR. vs. 148611
> From: Andrew Cooper
> Sent: Saturday, March 14, 2020 12:03 AM
>
> On 12/03/2020 23:56, osstest service owner wrote:
> > branch xen-unstable
> > xenbranch xen-unstable
> > job test-amd64-amd64-qemuu-nested-intel
> > testid debian-hvm-install/l1/l2
> >
> > Tree: linux
> From: Paul Durrant
> Sent: Friday, March 13, 2020 5:26 PM
>
> > -Original Message-
> > From: Jan Beulich
> > Sent: 13 March 2020 08:10
> > To: Tian, Kevin
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Paul Durrant
> >
> > Subject: Re: [PATCH v3] IOMMU: make DMA
> From: Paul Durrant
> Sent: Friday, March 13, 2020 5:26 PM
>
> > -Original Message-
> > From: Tian, Kevin
> > Sent: 13 March 2020 03:23
> > To: p...@xen.org; 'Jan Beulich'
> > Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
>
> > Subject: RE: [Xen-devel] [PATCH v3] IOMMU: make
75 matches
Mail list logo
