|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd
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@xxxxxxxx> 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@xxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |