From: Jan Beulich <jbeulich@suse.com>
To: xen-devel@lists.xenproject.org
Cc: osstest service owner <osstest-admin@xenproject.org>
Subject: Re: [linux-linus test] 171361: regressions - FAIL
Date: Mon, 27 Jun 2022 09:38:02 +0200 [thread overview]
Message-ID: <d9c96d44-ca77-3f96-7da6-301c88695126@suse.com> (raw)
In-Reply-To: <osstest-171361-mainreport@xen.org>
On 27.06.2022 03:38, osstest service owner wrote:
> flight 171361 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/171361/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-dom0pvh-xl-intel 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemut-win7-amd64 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-pygrub 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-freebsd11-amd64 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-qemuu-nested-amd 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemuu-win7-amd64 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-qemuu-ovmf-amd64 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl-xsm 8 xen-boot fail REGR. vs. 171277
> test-amd64-amd64-xl 8 xen-boot fail REGR. vs. 171277
At the example of this:
Jun 26 21:51:47.667404 mapping kernel into physical memory
Jun 26 21:51:47.667425 about to get started...
Jun 26 21:51:47.667435 (XEN) arch/x86/mm.c:2159:d0v0 Bad L1 flags 400000
Jun 26 21:51:47.667448 (XEN) Hardware Dom0 halted: halting machine
This is an attempt to install (modify?) a PTE with _PAGE_GNTTAB set
via normal page table management hypercalls. Considering how early in
the boot process this appears to be, I wonder whether a flag was
introduced in the kernel which aliases _PAGE_GNTTAB (or a use of such
a pre-existing flag on a path which previously was safe from being hit
when running in PV mode under Xen).
I wonder if the bisector is already having a go at isolating the
offending commit, or whether it had already failed in trying to.
Jan
next prev parent reply other threads:[~2022-06-27 7:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 1:38 [linux-linus test] 171361: regressions - FAIL osstest service owner
2022-06-27 7:38 ` Jan Beulich [this message]
2022-06-27 9:00 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9c96d44-ca77-3f96-7da6-301c88695126@suse.com \
--to=jbeulich@suse.com \
--cc=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.