[qemu-mainline test] 164950: tolerable FAIL - PUSHED

2021-09-12 Thread osstest service owner
flight 164950 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/164950/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail baseline untested test-amd64-amd64-xl-rtds 2

[libvirt test] 164953: regressions - FAIL

2021-09-12 Thread osstest service owner
flight 164953 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/164953/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt

[xen-unstable-coverity test] 164955: all pass - PUSHED

2021-09-12 Thread osstest service owner
flight 164955 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/164955/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 6d45368a0a89e01a3a01d156af61fea565db96cc baseline version: xen e70a

Re: [PATCH v3 21/30] target/ppc: Introduce PowerPCCPUClass::has_work()

2021-09-12 Thread Richard Henderson
On 9/11/21 3:31 PM, Philippe Mathieu-Daudé wrote: On 9/3/21 11:11 PM, Philippe Mathieu-Daudé wrote: On 9/3/21 10:42 PM, Richard Henderson wrote: On 9/3/21 2:50 AM, David Gibson wrote: On Thu, Sep 02, 2021 at 06:15:34PM +0200, Philippe Mathieu-Daudé wrote: Each POWER cpu has its own has_work()

[linux-linus test] 164952: regressions - FAIL

2021-09-12 Thread osstest service owner
flight 164952 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/164952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm 14 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl

[xen-unstable test] 164951: regressions - FAIL

2021-09-12 Thread osstest service owner
flight 164951 xen-unstable real [real] flight 164956 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/164951/ http://logs.test-lab.xenproject.org/osstest/logs/164956/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be r

[linux-5.4 test] 164954: regressions - trouble: blocked/broken/fail/pass

2021-09-12 Thread osstest service owner
flight 164954 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/164954/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xsm 4 host-install

[linux-linus test] 164957: regressions - FAIL

2021-09-12 Thread osstest service owner
flight 164957 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/164957/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl

[xen-unstable test] 164958: regressions - FAIL

2021-09-12 Thread osstest service owner
flight 164958 xen-unstable real [real] flight 164962 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/164958/ http://logs.test-lab.xenproject.org/osstest/logs/164962/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be r

[linux-5.4 test] 164960: tolerable FAIL - PUSHED

2021-09-12 Thread osstest service owner
flight 164960 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/164960/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail baseline untested test-amd64-amd64-xl-qemuu-win7-amd

Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub

2021-09-12 Thread Juergen Gross
On 10.09.21 17:32, Ian Jackson wrote: Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub"): BTW, you probably want to modify OSStest to use configure with: --enable-pv-grub --enable-qemu-traditional in order to not let the tests fail (applies to x86 only, of co

Re: [RFC PATCH] xen/gnttab: Store frame GFN in struct page_info on Arm

2021-09-12 Thread Jan Beulich
On 10.09.2021 09:52, Jan Beulich wrote: > On 10.09.2021 01:04, Oleksandr Tyshchenko wrote: >> @@ -731,11 +733,19 @@ static void p2m_put_l3_page(const lpae_t pte) >> */ >> if ( p2m_is_foreign(pte.p2m.type) ) >> { >> -mfn_t mfn = lpae_get_mfn(pte); >> - >> ASSERT(mfn_

[PATCH v2] x86: correct asm() constraints when dealing with immediate selector values

2021-09-12 Thread Jan Beulich
asm() constraints need to fit both the intended insn(s) which the respective operands are going to be used with as well as the actual kind of value specified. "m" (alone) together with a constant, however, leads to gcc saying error: memory input is not directly addressable while clang complains

Re: [PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m

2021-09-12 Thread Oleksandr Andrushchenko
On 11.09.21 00:41, Julien Grall wrote: > > > On Fri, 10 Sep 2021, 21:30 Stefano Stabellini, > wrote: > > On Fri, 10 Sep 2021, Julien Grall wrote: > > On 10/09/2021 15:01, Oleksandr Andrushchenko wrote: > > > On 10.09.21 16:18, Julien Grall wrote: > >

[PATCH 0/2] grant table and add-to-physmap adjustments on top of XSAs 379 and 384

2021-09-12 Thread Jan Beulich
I'm prepared for the "how" aspect of the 1st patch here to end up controversial. Since the observed quirk will imo want dealing with, I'd appreciate any objection to the proposed change to be accompanied by an alternative suggestion. An intention of mine was to not further increase the number of ar

[PATCH 1/2] gnttab: remove guest_physmap_remove_page() call from gnttab_map_frame()

2021-09-12 Thread Jan Beulich
Without holding appropriate locks, attempting to remove a prior mapping of the underlying page is pointless, as the same (or another) mapping could be re-established by a parallel request on another vCPU. Move the code to Arm's gnttab_set_frame_gfn(). Of course this new placement doesn't improve th

[PATCH 2/2] memory: XENMEM_add_to_physmap (almost) wrapping checks

2021-09-12 Thread Jan Beulich
Determining that behavior is correct (i.e. results in failure) for a passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit more obvious by checking input in generic code - both for singular requests to not match the value and for range ones to not pass / wrap through it. For Arm

Re: [PATCH v6 05/10] xsm: apply coding style

2021-09-12 Thread Jan Beulich
On 10.09.2021 22:13, Daniel P. Smith wrote: > Instead of intermixing coding style changes with code changes as they > are come upon in this patch set, moving all coding style changes > into a single commit. The focus of coding style changes here are, > > - move trailing comments to line above >