branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win10-i386
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> The new API is an exact match for the needs of radeon.
>
> For some reason radeon tries to remove overlapping ranges from the
> interval tree, but interval trees (and mmu_range_notifier_insert)
> support overlapping ranges d
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> find_vma() must be called under the mmap_sem, reorganize this code to
> do the vma check after entering the lock.
>
> Further, fix the unlocked use of struct task_struct's mm, instead use
> the mm from hmm_mirror which has a
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> Remove the interval tree in the driver and rely on the tree maintained by
> the mmu_notifier for delivering mmu_notifier invalidation callbacks.
>
> For some reason amdgpu has a very complicated arrangement where it tries
>
flight 143270 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 143242
test-amd64-amd64-xl-
On 10/28/19 18:05, Andrew Cooper wrote:
> On 25/10/2019 22:56, Norbert Manthey wrote:
>> On 10/25/19 17:40, Jan Beulich wrote:
>>> On 25.10.2019 17:27, Andrew Cooper wrote:
On 25/10/2019 13:34, Jan Beulich wrote:
> On 25.10.2019 14:10, Andrew Cooper wrote:
>> The two choices to unblock
flight 143281 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143281/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 13 guest-start.2 fail
REGR. vs. 142994
Tests whi
Once again RPL checks have been introduced which don't account for a
32-bit kernel living in ring 1 when running in a PV Xen domain. The
case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
as well just in case.
Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
On 28.10.2019 18:30, Stonehouse, Robert wrote:
> Reverting one hunk via the following commit fixes things for me (this is an
> experiment and not at all a proposed fix)
>
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -303,15 +303,15 @@ static void stop_this_cpu(void *dummy)
>
On 28/10/2019 11:33, Andrew Cooper wrote:
> On 28/10/2019 11:30, Jan Beulich wrote:
>> On 28.10.2019 12:15, Andrew Cooper wrote:
>>> On 28/10/2019 11:11, Jan Beulich wrote:
On 28.10.2019 12:08, Sergey Dyasli wrote:
> On 28/10/2019 09:06, Jan Beulich wrote:
>> On 28.10.2019 09:56, Serge
On 29/10/2019 10:17, Sergey Dyasli wrote:
> On 28/10/2019 11:33, Andrew Cooper wrote:
>> On 28/10/2019 11:30, Jan Beulich wrote:
>>> On 28.10.2019 12:15, Andrew Cooper wrote:
On 28/10/2019 11:11, Jan Beulich wrote:
> On 28.10.2019 12:08, Sergey Dyasli wrote:
>> On 28/10/2019 09:06, Jan
On 29/10/2019 10:19, Andrew Cooper wrote:
> On 29/10/2019 10:17, Sergey Dyasli wrote:
>> On 28/10/2019 11:33, Andrew Cooper wrote:
>>> For now, how about cpu_has_hypervisor ?
>>>
>>> Whatever the virtual environment, we should trust the provided memory map.
>> Unfortunately, this plan has failed: i
On 29/10/2019 10:40, Sergey Dyasli wrote:
> On 29/10/2019 10:19, Andrew Cooper wrote:
>> On 29/10/2019 10:17, Sergey Dyasli wrote:
>>> On 28/10/2019 11:33, Andrew Cooper wrote:
For now, how about cpu_has_hypervisor ?
Whatever the virtual environment, we should trust the provided memo
Hi,
Am Montag, 28. Oktober 2019, 18:30:12 CET schrieb Stonehouse, Robert:
> This is a heads-up as I have observed that the following commit (backported
> onto an Amazon 4.11 tree) causes kexec (and hence kdump) to fail.
>
> commit c719519a4183d0630121f6abeba420f49dbc3229
> Author: Jan B
On 28/10/2019 17:30, Stonehouse, Robert wrote:
> This is a heads-up as I have observed that the following commit (backported
> onto an Amazon 4.11 tree) causes kexec (and hence kdump) to fail.
>
> commit c719519a4183d0630121f6abeba420f49dbc3229
> Author: Jan Beulich
> AuthorDate: Fri Ju
On 29.10.2019 12:29, Sergey Dyasli wrote:
> On 28/10/2019 17:30, Stonehouse, Robert wrote:
>> This is a heads-up as I have observed that the following commit (backported
>> onto an Amazon 4.11 tree) causes kexec (and hence kdump) to fail.
>>
>> commit c719519a4183d0630121f6abeba420f49dbc
On 10/28/2019 4:10 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This converts one of the two users of mmu_notifiers to use the new API.
The conversion is fairly straightforward, however the existing use of
notifiers here seems to be racey.
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Sign
On Mon, 28 Oct 2019 at 16:38, Petre Pircalabu
wrote:
>
> gcc (GCC) 9.2.0 complains:
>
> xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
> xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier
> from pointer target type [-Werror=discarded-qualifiers]
>93 | valu
On Thu, 24 Oct 2019 at 14:01, Wei Liu wrote:
>
> Blktap2 is gone and tools/libs is missing in the document.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Juergen Gross
> Release-acked-by: Juergen Gross ---
> CONTRIBUTING | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/CONT
On Tue, Oct 29, 2019 at 08:19:20AM -0400, Dennis Dalessandro wrote:
> On 10/28/2019 4:10 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > This converts one of the two users of mmu_notifiers to use the new API.
> > The conversion is fairly straightforward, however the existing use of
>
On Tue, Oct 29, 2019 at 12:38:35PM +, Wei Liu wrote:
> On Mon, 28 Oct 2019 at 16:38, Petre Pircalabu
> wrote:
> >
> > gcc (GCC) 9.2.0 complains:
> >
> > xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
> > xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-xsm
testid guest-start
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://x
On 29/10/2019 08:25, Norbert Manthey wrote:
> On 10/28/19 18:05, Andrew Cooper wrote:
>> On 25/10/2019 22:56, Norbert Manthey wrote:
>>> On 10/25/19 17:40, Jan Beulich wrote:
On 25.10.2019 17:27, Andrew Cooper wrote:
> On 25/10/2019 13:34, Jan Beulich wrote:
>> On 25.10.2019 14:10, And
On Tue, Oct 29, 2019 at 07:51:30AM +, Koenig, Christian wrote:
> > +static bool amdgpu_mn_invalidate_gfx(struct mmu_range_notifier *mrn,
> > +const struct mmu_notifier_range *range)
> > {
> > - struct amdgpu_bo *bo;
> > + struct amdgpu_bo *bo = container_of
On 29.10.2019 14:46, Andrew Cooper wrote:
> If this patch series does not agreement, I will unblock livepatching on
> 4.13 by committing the v2 patch which causes BRANCH_HARDEN to depend on
> BROKEN and force it to be compiled out with no user choice at all.
>
> Unbreaking livepatching is strictly
Anthony PERARD writes ("Re: [RFC XEN PATCH for-4.13 0/4] Fix: libxl workaround,
multiple connection to single QMP socket"):
> Those suggestions are interesting idea, but I would prefer to have libxl
> been able to deal with any version of QEMU, so without having to patch
> QEMU. Beside serialising
Anthony PERARD writes ("Re: [RFC XEN PATCH for-4.13 1/4] libxl: Introduce
libxl__ev_child_kill"):
...
> > > +if (status) {
> > > +libxl_report_child_exitstatus(CTX, XTL_ERROR,
> > > + "killed fork (dying as expected)",
> > > +
On 29/10/2019 14:03, Jan Beulich wrote:
> On 29.10.2019 14:46, Andrew Cooper wrote:
>> If this patch series does not agreement, I will unblock livepatching on
>> 4.13 by committing the v2 patch which causes BRANCH_HARDEN to depend on
>> BROKEN and force it to be compiled out with no user choice at
Julien Grall writes ("Re: rochester and Debian buster"):
> I have just remembered that we are not using the on-board network card but
> instead a USB dongle.
Yes.
> But I am not sure which eth interface is linked to and how you found
> out the network is down.
I didn't have clear notes about th
On 28/10/2019 21:43, Stefano Stabellini wrote:
> On Mon, 28 Oct 2019, Julien Grall wrote:
>> Hi,
>>
>> On 25/10/2019 11:31, Jan Beulich wrote:
>>> All,
>>>
>>> the 4.11.3 stable release is due. I intend to wait for the XSA fixes
>>> going public on the 31st, but not (much) longer. Please point ou
On 10/29/19 15:16, Andrew Cooper wrote:
> On 29/10/2019 14:03, Jan Beulich wrote:
>> On 29.10.2019 14:46, Andrew Cooper wrote:
>>> If this patch series does not agreement, I will unblock livepatching on
>>> 4.13 by committing the v2 patch which causes BRANCH_HARDEN to depend on
>>> BROKEN and force
On 28.10.2019 16:01, Andrew Cooper wrote:
> At the time of fixing c/s 20f1976b44, no obvious errata had been published,
> and BDF14 looked like the most obvious candidate. Subsequently, BDF93 has
> been published and it is obviously this.
>
> The erratum states that LER_TO_LIP is the only affecte
On 29/10/2019 14:34, Jan Beulich wrote:
> On 28.10.2019 16:01, Andrew Cooper wrote:
>> At the time of fixing c/s 20f1976b44, no obvious errata had been published,
>> and BDF14 looked like the most obvious candidate. Subsequently, BDF93 has
>> been published and it is obviously this.
>>
>> The erra
On 29.10.2019 15:30, Julien Grall wrote:
>
>
> On 28/10/2019 21:43, Stefano Stabellini wrote:
>> On Mon, 28 Oct 2019, Julien Grall wrote:
>>> Hi,
>>>
>>> On 25/10/2019 11:31, Jan Beulich wrote:
All,
the 4.11.3 stable release is due. I intend to wait for the XSA fixes
going pub
Hi Jan,
On 29/10/2019 14:49, Jan Beulich wrote:
On 29.10.2019 15:30, Julien Grall wrote:
On 28/10/2019 21:43, Stefano Stabellini wrote:
On Mon, 28 Oct 2019, Julien Grall wrote:
Hi,
On 25/10/2019 11:31, Jan Beulich wrote:
All,
the 4.11.3 stable release is due. I intend to wait for the XSA
flight 143294 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143294/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4976a776b283021c252be794e90947732b6f8a92
baseline version:
ovmf 9e639c1cb6abd5ffed0f9
Hi,
I have made some comments regarding the patch in the original thread. While I am
not a libxl expert, it would have been nice to address them or at least explain
why they weren't addressed.
I will repeat them here for convenience.
On 28/10/2019 18:22, Oleksandr Grytsov wrote:
From: Oleks
On 29.10.2019 16:06, Julien Grall wrote:
> On 29/10/2019 14:49, Jan Beulich wrote:
>> This is quite long a list for a release about to be cut. Looking
>> at the branch I don't see any Arm backports other than the ones
>> done yesterday post-4.11.2. I'm fine with batching, but may I
>> ask for such
Oleksandr Grytsov writes ("[PATCH v1 1/1] libxl/gentypes: add range init to
array elements in json parsing"):
> From: Oleksandr Grytsov
>
> Add initialization of array elements in parse json function.
>
> Currently, array elements are initialized with calloc. Which means
> initialize all elemen
On 28.10.2019 16:01, Andrew Cooper wrote:
> Cross reference and list each errata, now that they are published.
Shouldn't this be "all errata" or "each erratum"?
> @@ -2727,40 +2719,50 @@ enum
>
> static bool __read_mostly lbr_tsx_fixup_needed;
> static bool __read_mostly bdf93_fixup_needed;
>
Julien Grall writes ("Re: [Xen-devel] [PATCH v1 1/1] libxl/gentypes: add range
init to array elements in json parsing"):
> I have made some comments regarding the patch in the original
> thread. While I am not a libxl expert, it would have been nice to
> address them or at least explain why they w
On 29/10/2019 15:32, Jan Beulich wrote:
> On 28.10.2019 16:01, Andrew Cooper wrote:
>> Cross reference and list each errata, now that they are published.
> Shouldn't this be "all errata" or "each erratum"?
Probably.
>
>> @@ -2727,40 +2719,50 @@ enum
>>
>> static bool __read_mostly lbr_tsx_fixu
Ian Jackson writes ("Re: [Xen-devel] [PATCH v1 1/1] libxl/gentypes: add range
init to array elements in json parsing"):
> Julien Grall writes ("Re: [Xen-devel] [PATCH v1 1/1] libxl/gentypes: add
> range init to array elements in json parsing"):
> > I am also not entirely sure whether we should al
Oleksandr Grytsov discovered that the libxl json idl parsing fails to
properly initialise array elements.
Fixing this is not entirely straightforward, because the code to do
the initialisation is not conveniently available as a separate
function.
To ease debugging and review, I have broken this p
We are going to want this in a moment.
No functional change with existing types: C output is identical.
Signed-off-by: Ian Jackson
---
tools/libxl/gentypes.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 1769
When both are provided, init_val is likely to be more direct.
No functional change with existing types: C output is identical.
Signed-off-by: Ian Jackson
---
tools/libxl/gentypes.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/gentypes.py b/tools/libxl/g
This is going to be the common way to initialise things.
_libxl_C_type_init remains the thing for generating the body of the
init function, and for some special cases.
No functional change with existing types: C output is identical.
Signed-off-by: Ian Jackson
---
tools/libxl/gentypes.py | 23 ++
From: Oleksandr Grytsov
Currently, array elements are initialized with calloc. Which means
initialize all element fields with zero values. If an entry is not
present in the json (which is entirely permitted), the element will be
all-bits-zero instead of the default value (which is wrong).
The
On 29.10.19 16:54, Ian Jackson wrote:
Oleksandr Grytsov discovered that the libxl json idl parsing fails to
properly initialise array elements.
Fixing this is not entirely straightforward, because the code to do
the initialisation is not conveniently available as a separate
function.
To ease de
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> find_vma() must be called under the mmap_sem, reorganize this code to
> do the vma check after entering the lock.
>
> Further, fix the unlocked use of struct task_struct's mm, instead use
> the mm from hmm_mirror which has
Wei Liu writes ("Re: [PATCH v2 for-4.13] CONTRIBUTING: drop blktap2 and add
tools/libs"):
> On Thu, 24 Oct 2019 at 14:01, Wei Liu wrote:
> > Blktap2 is gone and tools/libs is missing in the document.
> >
> > Signed-off-by: Wei Liu
> > Reviewed-by: Juergen Gross
> > Release-acked-by: Juergen Gro
On 25/10/2019 13:03, Jan Beulich wrote:
> On 23.10.2019 15:58, Andrew Cooper wrote:
>> evaluate_nospec() is incredibly fragile, and this is one giant bodge.
>>
>> To correctly protect jumps, the generated code needs to be of the form:
>>
>> cmp/test
>> jcc 1f
>> lfence
>> ...
>> 1
flight 143292 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which are faili
On 25/10/2019 13:09, Jan Beulich wrote:
> On 23.10.2019 15:58, Andrew Cooper wrote:
>> l1tf-barrier is an inappropriate name, and came about because of restrictions
>> on could be discussed publicly when the patches were proposed.
>>
>> In practice, it is for general Spectre v1 mitigations, and is
On 24/10/2019 13:03, Jan Beulich wrote:
> On 23.10.2019 15:58, Andrew Cooper wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP
>>
>>If unsure, say Y.
>>
>> +config ENFORCE_UNIQUE_SYMBOLS
>> +bool "Enforce unique symbols"
Am 29.10.19 um 17:28 schrieb Kuehling, Felix:
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead
On Tue, Oct 29, 2019 at 04:44:24PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2 for-4.13] CONTRIBUTING: drop blktap2 and add
> tools/libs"):
> > On Thu, 24 Oct 2019 at 14:01, Wei Liu wrote:
> > > Blktap2 is gone and tools/libs is missing in the document.
> > >
> > > Signed-off-by: W
On Tue, Oct 29, 2019 at 04:28:43PM +, Kuehling, Felix wrote:
> On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > find_vma() must be called under the mmap_sem, reorganize this code to
> > do the vma check after entering the lock.
> >
> > Further, fix the unlocked
flight 143341 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143341/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
The pvshim can only be built 64-bit because the hypervisor is only
64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
XEN_TARGET_ARCH which override the information from uname. The pvshim
build runs out of the tools/ directory but calls the hypervisor build
system.
If one runs i
On 29/10/2019 17:57, Ian Jackson wrote:
> The pvshim can only be built 64-bit because the hypervisor is only
> 64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
> XEN_TARGET_ARCH which override the information from uname. The pvshim
> build runs out of the tools/ directory but c
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, October 28, 2019 11:02 PM
>
> Cross reference and list each errata, now that they are published.
>
> These errata are specific to Haswell/Broadwell. They should have model
> and
> vendor checks, as Intel isn't the only vend
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, October 28, 2019 11:02 PM
>
> At the time of fixing c/s 20f1976b44, no obvious errata had been published,
> and BDF14 looked like the most obvious candidate. Subsequently, BDF93
> has
> been published and it is obviously thi
On Tue, 29 Oct 2019, Julien Grall wrote:
> On 28/10/2019 21:43, Stefano Stabellini wrote:
> > On Mon, 28 Oct 2019, Julien Grall wrote:
> >> Hi,
> >>
> >> On 25/10/2019 11:31, Jan Beulich wrote:
> >>> All,
> >>>
> >>> the 4.11.3 stable release is due. I intend to wait for the XSA fixes
> >>> going p
Andrew Cooper writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure:
Honour XEN_COMPILE_ARCH and _TARGET_ for shim"):
> On 29/10/2019 17:57, Ian Jackson wrote:
> > The pvshim can only be built 64-bit because the hypervisor is only
> > 64-bit nowadays. The hypervisor build supports XEN_COM
flight 143288 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 142750
On Tue, Oct 29, 2019 at 07:22:37PM +, Yang, Philip wrote:
> Hi Jason,
>
> I did quick test after merging amd-staging-drm-next with the
> mmu_notifier branch, which includes this set changes. The test result
> has different failures, app stuck intermittently, GUI no display etc. I
> am under
Hi Jason,
I did quick test after merging amd-staging-drm-next with the
mmu_notifier branch, which includes this set changes. The test result
has different failures, app stuck intermittently, GUI no display etc. I
am understanding the changes and will try to figure out the cause.
Regards,
Phili
flight 143277 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-exa
flight 143301 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143301/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 142915
test-amd64-amd64-
flight 143357 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143357/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
I haven't had enough time to fully understand the deferred logic in this
change. I spotted one problem, see comments inline.
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Of the 13 users of mmu_notifiers, 8 of them use only
> invalidate_range_start/end() and immedia
On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Remove the interval tree in the driver and rely on the tree maintained by
> the mmu_notifier for delivering mmu_notifier invalidation callbacks.
>
> For some reason amdgpu has a very complicated arrangement where it tries
flight 143302 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 143190
test-amd64-amd
On Tue, Oct 29, 2019 at 10:04:45PM +, Kuehling, Felix wrote:
> >* because mm->mm_users > 0 during mmu_notifier_register and exit_mmap
> > @@ -52,17 +286,24 @@ struct mmu_notifier_mm {
> >* can't go away from under us as exit_mmap holds an mm_count pin
> >* itself.
> >*/
> > -vo
On Tue, Oct 29, 2019 at 10:14:29PM +, Kuehling, Felix wrote:
> > +static const struct mmu_range_notifier_ops amdgpu_mn_hsa_ops = {
> > + .invalidate = amdgpu_mn_invalidate_hsa,
> > +};
> > +
> > +static int amdgpu_mn_sync_pagetables(struct hmm_mirror *mirror,
> > +
Hi Roger & Jan,
I got my test env back, and back the patch to stable-4.12, run same
test, I still seen original issue, guest kernel printed error:
kernel:do_IRQ: 20.114 No irq handler for vector (irq -1)
After that, pass through infiniband VF stopped to work.
My patch as below, please check:
flight 143367 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143367/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 143304 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143304/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 143158
test-amd64-amd
flight 143316 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 143023
test-amd64-amd64-libvir
80 matches
Mail list logo
