[ovmf test] 158292: all pass - PUSHED

flight 158292 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/158292/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf acabf1b0330897e4e0ac236d8930f2ded1c4ffb8 baseline version: ovmf 9783767fcfc253c74fe3a

[libvirt test] 158294: regressions - FAIL

flight 158294 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/158294/ 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 test] 158290: tolerable FAIL

flight 158290 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/158290/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158269 test-amd64-amd64-xl-qemuu-win7-amd64

RE: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles for Arm64

HI Julien, > -Original Message- > From: Julien Grall > Sent: 2021年1月8日 19:56 > To: Wei Chen ; xen-devel@lists.xenproject.org; > sstabell...@kernel.org > Cc: Bertrand Marquis ; Penny Zheng > ; Jiamei Xie ; nd > > Subject: Re: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles for

Re: [PATCH v4 02/10] evtchn: bind-interdomain doesn't need to hold both domains' event locks

Hi Jan, On 05/01/2021 13:09, Jan Beulich wrote: The local domain's lock is needed for the port allocation, but for the remote side the per-channel lock is sufficient. The per-channel locks then need to be acquired slightly earlier, though. I was expecting is little bit more information in the

Re: [PATCH v4 04/10] evtchn: don't call Xen consumer callback with per-channel lock held

Hi Jan, On 05/01/2021 13:10, Jan Beulich wrote: While there don't look to be any problems with this right now, the lock order implications from holding the lock can be very difficult to follow (and may be easy to violate unknowingly). The present callbacks don't (and no such callback should) hav

[qemu-mainline test] 158291: regressions - FAIL

flight 158291 qemu-mainline real [real] flight 158298 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/158291/ http://logs.test-lab.xenproject.org/osstest/logs/158298/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH v4 02/10] evtchn: bind-interdomain doesn't need to hold both domains' event locks

On 09/01/2021 15:41, Julien Grall wrote: Hi Jan, On 05/01/2021 13:09, Jan Beulich wrote: The local domain's lock is needed for the port allocation, but for the remote side the per-channel lock is sufficient. The per-channel locks then need to be acquired slightly earlier, though. I was exp

Re: [PATCH v4 05/10] evtchn: closing of vIRQ-s doesn't require looping over all vCPU-s

Hi Jan, On 05/01/2021 13:10, Jan Beulich wrote: Global vIRQ-s have their event channel association tracked on vCPU 0. Per-vCPU vIRQ-s can't have their notify_vcpu_id changed. Hence it is well-known which vCPU's virq_to_evtchn[] needs updating. I went through the history and couldn't find a rea

Re: [PATCH v4 06/10] evtchn: slightly defer lock acquire where possible

Hi Jan, On 05/01/2021 13:11, Jan Beulich wrote: port_is_valid() and evtchn_from_port() are fine to use without holding any locks. Per my remark in patch #1, currently, this only holds as long as we are checking the port for the current domain. If it were a different domain, then the risk a

Re: [PATCH v4 07/10] evtchn: add helper for port_is_valid() + evtchn_from_port()

Hi Jan, On 05/01/2021 13:12, Jan Beulich wrote: The combination is pretty common, so adding a simple local helper seems worthwhile. Make it const- and type-correct, in turn requiring the two called function to also be const-correct (and at this occasion also make them type-correct). Acked-by:

[linux-linus test] 158295: regressions - FAIL

flight 158295 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/158295/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-

Re: [PATCH v4 09/11] xen/arm: smmuv3: Use fallthrough pseudo-keyword

Hello Stefano, Thanks for reviewing the series. > On 9 Jan 2021, at 1:44 am, Stefano Stabellini wrote: > > On Fri, 8 Jan 2021, Rahul Singh wrote: >> Merge the patch from linux to use fallthrough pseudo-keyword. >> >> Replace the existing /* fall through */ comments and its variants with >> the

[xen-unstable test] 158296: regressions - FAIL

flight 158296 xen-unstable real [real] flight 158301 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/158296/ http://logs.test-lab.xenproject.org/osstest/logs/158301/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be r

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

flight 158297 linux-5.4 real [real] flight 158304 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/158297/ http://logs.test-lab.xenproject.org/osstest/logs/158304/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armh

[qemu-mainline test] 158299: regressions - FAIL

flight 158299 qemu-mainline real [real] flight 158312 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/158299/ http://logs.test-lab.xenproject.org/osstest/logs/158312/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be