* [xen-4.15-testing test] 164495: regressions - FAIL
@ 2021-08-27 6:52 osstest service owner
2021-08-27 13:29 ` XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL) Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: osstest service owner @ 2021-08-27 6:52 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 164495 xen-4.15-testing real [real]
flight 164509 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164495/
http://logs.test-lab.xenproject.org/osstest/logs/164509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 163759
test-amd64-amd64-dom0pvh-xl-intel 8 xen-boot fail REGR. vs. 163759
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 164509-retest
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 163759
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 163759
test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 163759
test-armhf-armhf-libvirt 16 saverestore-support-check fail like 163759
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 163759
test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 163759
test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 163759
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 163759
test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 163759
test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 163759
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 163759
test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass
test-amd64-amd64-libvirt 15 migrate-support-check fail never pass
test-arm64-arm64-xl 15 migrate-support-check fail never pass
test-arm64-arm64-xl 16 saverestore-support-check fail never pass
test-arm64-arm64-xl-seattle 15 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 16 saverestore-support-check fail never pass
test-amd64-i386-libvirt 15 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 15 migrate-support-check fail never pass
test-amd64-i386-xl-pvshim 14 guest-start fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass
test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 14 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass
test-armhf-armhf-xl 15 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass
test-armhf-armhf-xl 16 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 15 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 16 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 15 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass
version targeted for testing:
xen 91bb9e9b0c0e2af926ab08958f3d65f07a105cb6
baseline version:
xen dba774896f7dd74773c14d537643b7d7477fefcd
Last test of basis 163759 2021-07-17 04:12:25 Z 41 days
Failing since 164262 2021-08-19 17:07:29 Z 7 days 5 attempts
Testing same since 164495 2021-08-25 23:22:14 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD <anthony.perard@citrix.com>
Dario Faggioli <dfaggioli@suse.com>
Ian Jackson <iwj@xenproject.org>
Jan Beulich <jbeulich@suse.com>
Jane Malalane <jane.malalane@citrix.com>
Juergen Gross <jgross@suse.com>
Julien Grall <jgrall@amazon.com>
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Stefano Stabellini <sstabellini@kernel.org>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-amd64-coresched-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-coresched-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-dom0pvh-xl-amd fail
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-qemuu-freebsd11-amd64 pass
test-amd64-amd64-qemuu-freebsd12-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-dom0pvh-xl-intel fail
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-arm64-arm64-xl-seattle pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-arm64-arm64-xl-thunderx pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
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
Not pushing.
(No revision log; it would be 983 lines long.)
^ permalink raw reply [flat|nested] 4+ messages in thread
* XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL)
2021-08-27 6:52 [xen-4.15-testing test] 164495: regressions - FAIL osstest service owner
@ 2021-08-27 13:29 ` Jan Beulich
2021-08-27 14:46 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2021-08-27 13:29 UTC (permalink / raw)
To: xen-devel; +Cc: osstest service owner
On 27.08.2021 08:52, osstest service owner wrote:
> flight 164495 xen-4.15-testing real [real]
> flight 164509 xen-4.15-testing real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/164495/
> http://logs.test-lab.xenproject.org/osstest/logs/164509/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 163759
> test-amd64-amd64-dom0pvh-xl-intel 8 xen-boot fail REGR. vs. 163759
This is fallout from XSA-378. During Dom0 setup we first call
iommu_hwdom_init(), which maps reserved regions (p2m_access_rw).
Later map_mmio_regions() gets used to identity-map the low first
Mb. This, using set_mmio_p2m_entry(), establishes default-access
mappings (p2m_access_rwx).
Hence even if relaxing the logic in set_typed_p2m_entry() to
if ( p2m_is_special(ot) )
{
gfn_unlock(p2m, gfn, order);
if ( mfn_eq(mfn, omfn) && gfn_p2mt == ot && access == a )
return 0;
domain_crash(d);
return -EPERM;
}
we're still in trouble (because the two access types don't match)
when there is any reserved region below 1Mb.
One approach would be to avoid blindly mapping the low first Mb,
and to instead honor mappings which are already there. Or the
opposite - avoid mapping anything from arch_iommu_hwdom_init()
which is below 1Mb. (Other mappings down the call tree from
pvh_setup_acpi() imo would then also need adjusting, to avoid
redundant mapping attempts of space below 1Mb. At least RSDP is
known to possibly live there on various systems.)
Another approach could be to stop passing ->default_access from
set_mmio_p2m_entry() to set_typed_p2m_entry(). (And I think the
same should go for set_foreign_p2m_entry()). At the very least
right now it makes no sense at all to make RWX mappings there,
except when mapping PCI device ROMs. But of course reducing
permissions always comes with a (however large or small) risk of
regressions.
While I think the latter aspect wants improving in any event,
right now I'm leaning towards the "opposite" variant of the
former. I'll draft a patch along these lines at least to see if
it helps, or if there is yet more fallout.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL)
2021-08-27 13:29 ` XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL) Jan Beulich
@ 2021-08-27 14:46 ` Jan Beulich
2021-08-30 10:25 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2021-08-27 14:46 UTC (permalink / raw)
To: xen-devel; +Cc: osstest service owner
On 27.08.2021 15:29, Jan Beulich wrote:
> On 27.08.2021 08:52, osstest service owner wrote:
>> flight 164495 xen-4.15-testing real [real]
>> flight 164509 xen-4.15-testing real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/164495/
>> http://logs.test-lab.xenproject.org/osstest/logs/164509/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 163759
>> test-amd64-amd64-dom0pvh-xl-intel 8 xen-boot fail REGR. vs. 163759
>
> This is fallout from XSA-378. During Dom0 setup we first call
> iommu_hwdom_init(), which maps reserved regions (p2m_access_rw).
> Later map_mmio_regions() gets used to identity-map the low first
> Mb. This, using set_mmio_p2m_entry(), establishes default-access
> mappings (p2m_access_rwx).
>
> Hence even if relaxing the logic in set_typed_p2m_entry() to
>
> if ( p2m_is_special(ot) )
> {
> gfn_unlock(p2m, gfn, order);
> if ( mfn_eq(mfn, omfn) && gfn_p2mt == ot && access == a )
> return 0;
> domain_crash(d);
> return -EPERM;
> }
>
> we're still in trouble (because the two access types don't match)
> when there is any reserved region below 1Mb.
>
> One approach would be to avoid blindly mapping the low first Mb,
> and to instead honor mappings which are already there. Or the
> opposite - avoid mapping anything from arch_iommu_hwdom_init()
> which is below 1Mb. (Other mappings down the call tree from
> pvh_setup_acpi() imo would then also need adjusting, to avoid
> redundant mapping attempts of space below 1Mb. At least RSDP is
> known to possibly live there on various systems.)
>
> Another approach could be to stop passing ->default_access from
> set_mmio_p2m_entry() to set_typed_p2m_entry(). (And I think the
> same should go for set_foreign_p2m_entry()). At the very least
> right now it makes no sense at all to make RWX mappings there,
> except when mapping PCI device ROMs. But of course reducing
> permissions always comes with a (however large or small) risk of
> regressions.
>
> While I think the latter aspect wants improving in any event,
> right now I'm leaning towards the "opposite" variant of the
> former. I'll draft a patch along these lines at least to see if
> it helps, or if there is yet more fallout.
There is more fallout - with the initial issue addressed as
described I'm now hitting another similar domain_crash() in
guest_physmap_add_entry(). There's no question there whether to
check that old and new mappings match - they are different. Here
PVH Dom0 setup really does what the final XSA-378 patch is
intended to disallow: It produces MMIO mappings to then replace
some (or really most) by RAM ones. This means I'll have to
further adjust how pvh_populate_p2m() works. This will have to
wait until after the weekend, sorry.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL)
2021-08-27 14:46 ` Jan Beulich
@ 2021-08-30 10:25 ` Jan Beulich
0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2021-08-30 10:25 UTC (permalink / raw)
To: xen-devel; +Cc: osstest service owner
On 27.08.2021 16:46, Jan Beulich wrote:
> On 27.08.2021 15:29, Jan Beulich wrote:
>> On 27.08.2021 08:52, osstest service owner wrote:
>>> flight 164495 xen-4.15-testing real [real]
>>> flight 164509 xen-4.15-testing real-retest [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/164495/
>>> http://logs.test-lab.xenproject.org/osstest/logs/164509/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-amd64-amd64-dom0pvh-xl-amd 8 xen-boot fail REGR. vs. 163759
>>> test-amd64-amd64-dom0pvh-xl-intel 8 xen-boot fail REGR. vs. 163759
>>
>> This is fallout from XSA-378. During Dom0 setup we first call
>> iommu_hwdom_init(), which maps reserved regions (p2m_access_rw).
>> Later map_mmio_regions() gets used to identity-map the low first
>> Mb. This, using set_mmio_p2m_entry(), establishes default-access
>> mappings (p2m_access_rwx).
>>
>> Hence even if relaxing the logic in set_typed_p2m_entry() to
>>
>> if ( p2m_is_special(ot) )
>> {
>> gfn_unlock(p2m, gfn, order);
>> if ( mfn_eq(mfn, omfn) && gfn_p2mt == ot && access == a )
>> return 0;
>> domain_crash(d);
>> return -EPERM;
>> }
>>
>> we're still in trouble (because the two access types don't match)
>> when there is any reserved region below 1Mb.
>>
>> One approach would be to avoid blindly mapping the low first Mb,
>> and to instead honor mappings which are already there. Or the
>> opposite - avoid mapping anything from arch_iommu_hwdom_init()
>> which is below 1Mb. (Other mappings down the call tree from
>> pvh_setup_acpi() imo would then also need adjusting, to avoid
>> redundant mapping attempts of space below 1Mb. At least RSDP is
>> known to possibly live there on various systems.)
>>
>> Another approach could be to stop passing ->default_access from
>> set_mmio_p2m_entry() to set_typed_p2m_entry(). (And I think the
>> same should go for set_foreign_p2m_entry()). At the very least
>> right now it makes no sense at all to make RWX mappings there,
>> except when mapping PCI device ROMs. But of course reducing
>> permissions always comes with a (however large or small) risk of
>> regressions.
>>
>> While I think the latter aspect wants improving in any event,
>> right now I'm leaning towards the "opposite" variant of the
>> former. I'll draft a patch along these lines at least to see if
>> it helps, or if there is yet more fallout.
>
> There is more fallout - with the initial issue addressed as
> described I'm now hitting another similar domain_crash() in
> guest_physmap_add_entry(). There's no question there whether to
> check that old and new mappings match - they are different. Here
> PVH Dom0 setup really does what the final XSA-378 patch is
> intended to disallow: It produces MMIO mappings to then replace
> some (or really most) by RAM ones. This means I'll have to
> further adjust how pvh_populate_p2m() works.
And with this taken care of I'm hitting the original assertion
again, now in the course of mapping ACPI memory. This time the
collision is between RMRRs getting identity mapped first, and on
this box an RMRR region being enclosed by an ACPI NVS region of
the E820 map (and hence the _almost_ same mapping getting
requested a 2nd time). As a first step I'll further relax the
adjustment to set_typed_p2m_entry() still in context above. But
I'd be really thankful for thoughts by anyone else on how to
deal with all of this mess.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-08-30 10:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-27 6:52 [xen-4.15-testing test] 164495: regressions - FAIL osstest service owner
2021-08-27 13:29 ` XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL) Jan Beulich
2021-08-27 14:46 ` Jan Beulich
2021-08-30 10:25 ` Jan Beulich
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.