* [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd
@ 2017-02-23 22:54 osstest service owner
2017-02-23 23:40 ` Andrew Cooper
0 siblings, 1 reply; 3+ messages in thread
From: osstest service owner @ 2017-02-23 22:54 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-amd
testid xen-boot/l1
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 49de10f3c1718bb952f4b075d07f37eb9f605b2b
Bug not present: 38b48605f3693e950bb4155ea8dac6614d796c2b
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106036/
commit 49de10f3c1718bb952f4b075d07f37eb9f605b2b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Nov 2 14:36:49 2016 +0000
x86/hvm: Don't raise #GP behind the emulators back for MSR accesses
The current hvm_msr_{read,write}_intercept() infrastructure calls
hvm_inject_hw_exception() directly to latch a fault, and returns
X86EMUL_EXCEPTION to its caller.
This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
fault is raised behind the back of the x86 emulator.
Alter the behaviour so hvm_msr_{read,write}_intercept() simply returns
X86EMUL_EXCEPTION, leaving the callers to actually inject the #GP fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1 --summary-out=tmp/106036.bisection-summary --basis-template=105933 --blessings=real,real-bisect xen-unstable test-amd64-amd64-qemuu-nested-amd xen-boot/l1
Searching for failure / basis pass:
105994 fail [host=nocera1] / 105946 ok.
Failure / basis pass flights: 105994 / 105946
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 80a7d04f532ddc3500acd7988917708a536ae15f
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 5dbd60e16a1f29b9f1f84088c5cab1be2dac7a7a
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#b669e922b37b8957248798a5eb7aa96a666cd3fe-b669e922b37b8957248798a5eb7aa96a666cd3fe git://xenbits.xen.org/qemu-xen.git#08c008de9c7d3ac71f71c87cc04a47819ca228dc-57e8fbb2f702001a18bd81e9fe31b26d94247ac9 git://xenbits.xen.org/xen.git#5dbd60e16a1f29b9f1f84088c5cab1be2dac7a7a-80a7d04f532ddc3500acd7988917708a536ae15f
Loaded 2005 nodes in revision graph
Searching for test results:
105933 pass irrelevant
105946 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 5dbd60e16a1f29b9f1f84088c5cab1be2dac7a7a
106017 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 49de10f3c1718bb952f4b075d07f37eb9f605b2b
105995 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 5dbd60e16a1f29b9f1f84088c5cab1be2dac7a7a
105966 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc b908131167a67a16fbe9c7a7826b67e2d93d9ec5
106005 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc b908131167a67a16fbe9c7a7826b67e2d93d9ec5
106020 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 38b48605f3693e950bb4155ea8dac6614d796c2b
106036 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 49de10f3c1718bb952f4b075d07f37eb9f605b2b
106008 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 394e66b0d04f0281b9c6231dad1377c4b9fea7d0
106026 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 38b48605f3693e950bb4155ea8dac6614d796c2b
106012 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 49de10f3c1718bb952f4b075d07f37eb9f605b2b
106013 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 38b48605f3693e950bb4155ea8dac6614d796c2b
106022 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 49de10f3c1718bb952f4b075d07f37eb9f605b2b
105994 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 80a7d04f532ddc3500acd7988917708a536ae15f
106033 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 80a7d04f532ddc3500acd7988917708a536ae15f
Searching for interesting versions
Result found: flight 105946 (pass), for basis pass
Result found: flight 105994 (fail), for basis failure
Repro found: flight 105995 (pass), for basis pass
Repro found: flight 106033 (fail), for basis failure
0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 38b48605f3693e950bb4155ea8dac6614d796c2b
No revisions left to test, checking graph state.
Result found: flight 106013 (pass), for last pass
Result found: flight 106017 (fail), for first failure
Repro found: flight 106020 (pass), for last pass
Repro found: flight 106022 (fail), for first failure
Repro found: flight 106026 (pass), for last pass
Repro found: flight 106036 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 49de10f3c1718bb952f4b075d07f37eb9f605b2b
Bug not present: 38b48605f3693e950bb4155ea8dac6614d796c2b
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106036/
commit 49de10f3c1718bb952f4b075d07f37eb9f605b2b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Nov 2 14:36:49 2016 +0000
x86/hvm: Don't raise #GP behind the emulators back for MSR accesses
The current hvm_msr_{read,write}_intercept() infrastructure calls
hvm_inject_hw_exception() directly to latch a fault, and returns
X86EMUL_EXCEPTION to its caller.
This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
fault is raised behind the back of the x86 emulator.
Alter the behaviour so hvm_msr_{read,write}_intercept() simply returns
X86EMUL_EXCEPTION, leaving the callers to actually inject the #GP fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1.{dot,ps,png,html,svg}.
----------------------------------------
106036: tolerable ALL FAIL
flight 106036 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/106036/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail baseline untested
jobs:
test-amd64-amd64-qemuu-nested-amd fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd
2017-02-23 22:54 [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd osstest service owner
@ 2017-02-23 23:40 ` Andrew Cooper
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cooper @ 2017-02-23 23:40 UTC (permalink / raw)
To: osstest service owner, xen-devel, Jan Beulich
On 23/02/2017 22:54, osstest service owner wrote:
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: 49de10f3c1718bb952f4b075d07f37eb9f605b2b
> Bug not present: 38b48605f3693e950bb4155ea8dac6614d796c2b
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106036/
>
>
> commit 49de10f3c1718bb952f4b075d07f37eb9f605b2b
> Author: Andrew Cooper <andrew.cooper3@citrix.com>
> Date: Wed Nov 2 14:36:49 2016 +0000
>
> x86/hvm: Don't raise #GP behind the emulators back for MSR accesses
>
Jan: your gut feel was spot on.
This time,
Feb 23 22:30:29.269782 (XEN) d3v0: Invalid EFER update: 0x1d01 -> 0x3901
- LMSLE without support
Feb 23 22:30:52.069589 (XEN) hvm.c:1616:d3v0 All CPUs offline --
powering off.
From the L1 serial log
(http://logs.test-lab.xenproject.org/osstest/logs/106036/test-amd64-amd64-qemuu-nested-amd/nocera1---var-log-xen-osstest-serial-l1.guest.osstest.log)
(XEN) mwait-idle: does not run on family 16 model 8
(XEN) HVM: ASIDs enabled.
(XEN) *** DOUBLE FAULT ***
(XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d0801ed997>] svm.c#svm_cpu_up+0x1ba/0x21f
(XEN) RFLAGS: 0000000000010256 CONTEXT: hypervisor
(XEN) rax: 0000000000003d01 rbx: ffff82d080336080 rcx: 00000000c0000080
(XEN) rdx: 0000000000000000 rsi: 0000000000001d01 rdi: 0000000000000000
(XEN) rbp: ffff82d080317d98 rsp: ffff82d080317d88 r8: ffff8300bf55c000
(XEN) r9: 0000000000000000 r10: ffff82d080317d28 r11: 00000000ffffffff
(XEN) r12: ffff82d0802d9cc0 r13: ffff82d080317fff r14: 0000000000000000
(XEN) r15: ffff82d08034ba80 cr0: 000000008005003b cr4: 00000000000006e0
(XEN) cr3: 00000000bf505000 cr2: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Valid stack range: ffff82d080316000-ffff82d080318000,
sp=ffff82d080317d88, tss.esp0=ffff82d080317fc0
(XEN) No stack overflow detected. Skipping stack trace.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) DOUBLE FAULT -- system shutdown
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
The problem is that hvm_msr_write_intercept() calls hvm_set_efer() and
has an escape path which skipped the previous gp_fault path which I
edited. hvm_set_efer() raises #GP itself, returns X86EMUL_EXCEPTION,
which causes svm_do_msr_access() to raise #GP a second time. (It also
means that across a XenServer extended test, not a single VM ever make a
write to EFER which faulted...)
I already have a task on my TODO list to modify hvm_set_cr$N() & friends
to avoid raising exceptions behind the emulators back, which I believe
is the final task to fixing:
/*
* TODO: Make this true:
*
ASSERT(ctxt->event_pending == (rc == X86EMUL_EXCEPTION));
*
* Some codepaths still raise exceptions behind the back of the ...
Looks like this has just jumped to the top of my priority list.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd
@ 2021-07-10 21:53 osstest service owner
0 siblings, 0 replies; 3+ messages in thread
From: osstest service owner @ 2021-07-10 21:53 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-amd
testid xen-boot/l1
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: bfcdaae9c210bd7984d7691285aaf43deb1b0604
Bug not present: 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/163542/
commit bfcdaae9c210bd7984d7691285aaf43deb1b0604
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Jul 9 08:28:14 2021 +0200
x86/AMD: expose SYSCFG, TOM, TOM2, and IORRs to Dom0
Sufficiently old Linux (3.12-ish) accesses these MSRs (with the
exception of IORRs) in an unguarded manner. Furthermore these same MSRs,
at least on Fam11 and older CPUs, are also consulted by modern Linux,
and their (bogus) built-in zapping of #GP faults from MSR accesses leads
to it effectively reading zero instead of the intended values, which are
relevant for PCI BAR placement (which ought to all live in MMIO-type
space, not in DRAM-type one).
For SYSCFG, only certain bits get exposed. Since MtrrVarDramEn also
covers the IORRs, expose them as well. Introduce (consistently named)
constants for the bits we're interested in and use them in pre-existing
code as well. While there also drop the unused and somewhat questionable
K8_MTRR_RDMEM_WRMEM_MASK. To complete the set of memory type and DRAM vs
MMIO controlling MSRs, also expose TSEG_{BASE,MASK} (the former also
gets read by Linux, dealing with which was already the subject of
6eef0a99262c ["x86/PV: conditionally avoid raising #GP for early guest
MSR reads"]).
As a welcome side effect, verbosity on/of debug builds gets (perhaps
significantly) reduced.
Note that at least as far as those MSR accesses by Linux are concerned,
there's no similar issue for DomU-s, as the accesses sit behind PCI
device matching logic. The checked for devices would never be exposed to
DomU-s in the first place. Nevertheless I think that at least for HVM we
should return sensible values, not 0 (as svm_msr_read_intercept() does
right now). The intended values may, however, need to be determined by
hvmloader, and then get made known to Xen.
Fixes: 322ec7c89f66 ("x86/pv: disallow access to unknown MSRs")
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1 --summary-out=tmp/163542.bisection-summary --basis-template=163458 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-amd64-qemuu-nested-amd xen-boot/l1
Searching for failure / basis pass:
163506 fail [host=pinot0] / 163458 ok.
Failure / basis pass flights: 163506 / 163458
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0f435e2b58543f5baae96e17a10ae20d3dbc28fa
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#136c34c9bc4179dc64b15b2bb5f0c54\
ca4ddf823-136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 git://xenbits.xen.org/xen.git#0f435e2b58543f5baae96e17a10ae20d3dbc28fa-6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
Loaded 5001 nodes in revision graph
Searching for test results:
163458 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0f435e2b58543f5baae96e17a10ae20d3dbc28fa
163478 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
163508 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0f435e2b58543f5baae96e17a10ae20d3dbc28fa
163518 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
163521 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 836314747b0fd1688fc9526f7c73fd9313ba82f3
163506 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
163523 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111
163528 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 bfcdaae9c210bd7984d7691285aaf43deb1b0604
163534 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111
163537 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 bfcdaae9c210bd7984d7691285aaf43deb1b0604
163539 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111
163542 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 bfcdaae9c210bd7984d7691285aaf43deb1b0604
Searching for interesting versions
Result found: flight 163458 (pass), for basis pass
For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111, results HASH(0x5587144c06f0) HASH(0x5587144d0c00) HASH(0x5587144cd070) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9b\
c4179dc64b15b2bb5f0c54ca4ddf823 0f435e2b58543f5baae96e17a10ae20d3dbc28fa, results HASH(0x5587144c8738) HASH(0x5587144c3980) Result found: flight 163478 (fail), for basis failure (at ancestor ~620)
Repro found: flight 163508 (pass), for basis pass
Repro found: flight 163518 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111
No revisions left to test, checking graph state.
Result found: flight 163523 (pass), for last pass
Result found: flight 163528 (fail), for first failure
Repro found: flight 163534 (pass), for last pass
Repro found: flight 163537 (fail), for first failure
Repro found: flight 163539 (pass), for last pass
Repro found: flight 163542 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: bfcdaae9c210bd7984d7691285aaf43deb1b0604
Bug not present: 0cbed4f0fd94a7fd40662fb0b4b82a58abeca111
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/163542/
commit bfcdaae9c210bd7984d7691285aaf43deb1b0604
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Jul 9 08:28:14 2021 +0200
x86/AMD: expose SYSCFG, TOM, TOM2, and IORRs to Dom0
Sufficiently old Linux (3.12-ish) accesses these MSRs (with the
exception of IORRs) in an unguarded manner. Furthermore these same MSRs,
at least on Fam11 and older CPUs, are also consulted by modern Linux,
and their (bogus) built-in zapping of #GP faults from MSR accesses leads
to it effectively reading zero instead of the intended values, which are
relevant for PCI BAR placement (which ought to all live in MMIO-type
space, not in DRAM-type one).
For SYSCFG, only certain bits get exposed. Since MtrrVarDramEn also
covers the IORRs, expose them as well. Introduce (consistently named)
constants for the bits we're interested in and use them in pre-existing
code as well. While there also drop the unused and somewhat questionable
K8_MTRR_RDMEM_WRMEM_MASK. To complete the set of memory type and DRAM vs
MMIO controlling MSRs, also expose TSEG_{BASE,MASK} (the former also
gets read by Linux, dealing with which was already the subject of
6eef0a99262c ["x86/PV: conditionally avoid raising #GP for early guest
MSR reads"]).
As a welcome side effect, verbosity on/of debug builds gets (perhaps
significantly) reduced.
Note that at least as far as those MSR accesses by Linux are concerned,
there's no similar issue for DomU-s, as the accesses sit behind PCI
device matching logic. The checked for devices would never be exposed to
DomU-s in the first place. Nevertheless I think that at least for HVM we
should return sensible values, not 0 (as svm_msr_read_intercept() does
right now). The intended values may, however, need to be determined by
hvmloader, and then get made known to Xen.
Fixes: 322ec7c89f66 ("x86/pv: disallow access to unknown MSRs")
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1.{dot,ps,png,html,svg}.
----------------------------------------
163542: tolerable ALL FAIL
flight 163542 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/163542/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 16 xen-boot/l1 fail baseline untested
jobs:
test-amd64-amd64-qemuu-nested-amd fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-07-10 21:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-23 22:54 [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd osstest service owner
2017-02-23 23:40 ` Andrew Cooper
-- strict thread matches above, loose matches on Subject: below --
2021-07-10 21:53 osstest service owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).