Re: smmuv1 breakage
Hi Stefano, > On 22 Jun 2021, at 10:06 pm, Stefano Stabellini > wrote: > > Hi Rahul, > > Do you have an opinion on how we should move forward on this? > > Do you think it is OK to go for a full revert of "xen/arm: smmuv1: > Intelligent SMR allocation" or do you think it is best to go with an > alternative fix? If so, do you have something in mind? > Sorry for the late reply I was working on another high-priority task. I will work on this will try to fix the issue. I will update you within 2-3 days. Regards, Rahul > > > On Tue, 15 Jun 2021, Stefano Stabellini wrote: >> On Tue, 15 Jun 2021, Rahul Singh wrote: >>> Hi Stefano >>> On 15 Jun 2021, at 3:21 am, Stefano Stabellini wrote: Hi Rahul, Unfortunately, after bisecting, I discovered a few more breakages due to your smmuv1 series (commits e889809b .. 3e6047ddf) on Xilinx ZynqMP. I attached the DTB as reference. Please note that I made sure to cherry-pick "xen/arm: smmuv1: Revert associating the group pointer with the S2CR" during bisection. So the errors are present also on staging. The first breakage is an error at boot time in smmu.c#find_smmu_master, see log1. I think it is due to the lack of ability to parse the new smmu bindings in the old smmu driver. After removing all the "smmus" and "#stream-id-cells" properties in device tree, I get past the previous error, everything seems to be OK at early boot, but I actually get SMMU errors as soon as dom0 starting using devices: (XEN) smmu: /smmu@fd80: Unexpected global fault, this could be serious (XEN) smmu: /smmu@fd80: GFSR 0x8002, GFSYNR0 0x, GFSYNR1 0x0877, GFSYNR2 0x >>> >>> This fault is "Unidentified stream fault” for StreamID “ 0x877” that means >>> SMMU SMR is not configured for streamID “0x877" >>> >>> [ 10.419681] macb ff0e.ethernet eth0: DMA bus error: HRESP not OK [ 10.426452] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Do you think you'll be able to help fix them? You should be able to reproduce the two issues using Xilinx QEMU (but to be honest I haven't tested it on QEMU yet, I was testing on real hardware): - clone and compile xilinx QEMU https://github.com/Xilinx/qemu.git ./configure --target-list=aarch64-softmmu make - clone and build git://github.com/Xilinx/qemu-devicetrees.git - use the attached script to run it - kernel can be upstream defconfig 5.10 >>> >>> I tried to reproduce the issue on Xilinx QEMU as per the steps shared above >>> but I am not observing any issue on Xilinx QEMU. >> >> I tried on QEMU and it doesn't repro. I cannot explain why it works on >> QEMU and it fails on real hardware. >> >> >>> I also tested and confirmed on QEMU that SMMU is configured correctly >>> for specifically StreamID “ 0x877” and for other streamIDs. >>> >>> I check the xen.dtb shared by you and found out the there is no >>> "stream-id-cells” >>> property in the master device but the "mmu-masters" property is present in >>> the >>> smmu node. For legacy smmu binding we need both "stream-id-cells” and >>> "mmu-masters”. >>> If you need to add the new smmu binding please add the "iommu-cells” >>> property in the smmu node and the “iommus” property in the master device. >> >> In regards to the missing "stream-id-cells" property, I shared the wrong >> dtb before, sorry. I was running a number of tests and I might have >> picked the wrong file. The proper dtb comes with "stream-id-cells" for >> the 0x877 device, see attached. >> >> >> >>> Can you please share the xen boot logs with me so that I can debug further >>> why the error is observed? >> >> See attached. I did some debugging and discovered that it crashes while >> accessing master->of_node in find_smmu_master. If I revert your series, >> the crash goes away. It is very strange because your patches don't touch >> find_smmu_master or insert_smmu_master directly. >> >> I did a git reset --hard on the commit "xen/arm: smmuv1: Add a stream >> map entry iterator" and it worked, which points to "xen/arm: smmuv1: >> Intelligent SMR allocation" being the problem, even if I have the revert >> cherry-picked on top. Maybe the revert is not reverting enough? >> >> After this test, I switched back to staging and did: >> git revert 9f6cd4983715cb31f0ea540e6bbb63f799a35d8a >> git revert 0435784cc75dcfef3b5f59c29deb1dbb84265ddb >> >> And it worked! So the issue truly is that >> 9f6cd4983715cb31f0ea540e6bbb63f799a35d8a doesn't revert "enough". >> See "full-revert" for the patch reverting the remaining code. That on >> top of staging fixes boot for me.
Re: [PATCH v14 00/12] Restricted DMA
On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote: > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage or corruption. > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > not behind an IOMMU. As PCI-e, by design, gives the device full access to > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > full chain of exploits; [2], [3]). > > To mitigate the security concerns, we introduce restricted DMA. Restricted > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > specially allocated region and does memory allocation from the same region. > The feature on its own provides a basic level of protection against the DMA > overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system needs > to provide a way to restrict the DMA to a predefined memory region (this is > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > [1a] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > [1b] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > [2] https://blade.tencent.com/en/advisories/qualpwn/ > [3] > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > [4] > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 Heya Claire, I put all your patches on https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/log/?h=devel/for-linus-5.14 Please double-check that they all look ok. Thank you!
Re: [PATCH V7 01/18] perf/core: Use static_call to optimize perf_guest_info_callbacks
Thanks Boris, I will fix this in V8
On 6/23/2021 1:31 AM, Boris Ostrovsky wrote:
On 6/22/21 5:38 AM, Zhu Lingshan wrote:
-static int xen_is_user_mode(void)
-{
- const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
+ state |= PERF_GUEST_ACTIVE;
- if (!xenpmu_data) {
- pr_warn_once("%s: pmudata not initialized\n", __func__);
- return 0;
+ if (xenpmu_data->pmu.pmu_flags & PMU_SAMPLE_PV) {
+ if (xenpmu_data->pmu.pmu_flags & PMU_SAMPLE_USER)
+ state |= PERF_GUEST_USER;
+ } else {
+ if (!!(xenpmu_data->pmu.r.regs.cpl & 3))
+ state |= PERF_GUEST_USER;
Please drop "!!", it's not needed here. And use "else if".
With that, for Xen bits:
Reviewed-by: Boris Ostrovsky
-boris
Re: [PATCH v14 00/12] Restricted DMA
On Wed, Jun 23, 2021 at 4:38 PM Konrad Rzeszutek Wilk wrote: > > On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote: > > This series implements mitigations for lack of DMA access control on > > systems without an IOMMU, which could result in the DMA accessing the > > system memory at unexpected times and/or unexpected addresses, possibly > > leading to data leakage or corruption. > > > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > > not behind an IOMMU. As PCI-e, by design, gives the device full access to > > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > > full chain of exploits; [2], [3]). > > > > To mitigate the security concerns, we introduce restricted DMA. Restricted > > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > > specially allocated region and does memory allocation from the same region. > > The feature on its own provides a basic level of protection against the DMA > > overwriting buffer contents at unexpected times. However, to protect > > against general data leakage and system memory corruption, the system needs > > to provide a way to restrict the DMA to a predefined memory region (this is > > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > > > [1a] > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > > [1b] > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > > [2] https://blade.tencent.com/en/advisories/qualpwn/ > > [3] > > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > > [4] > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > Heya Claire, > > I put all your patches on > https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/log/?h=devel/for-linus-5.14 > > Please double-check that they all look ok. > > Thank you! They look fine. Thank you!
Welcome Ashley Weltz, the new XenProject Project Coordinator
Hello everyone! Please welcome Ashley Weltz, our new Project Coordinator from the Linux Foundation. As the job title implies, Ashley will be helping out with various project coordination activities, including chairing the monthly community call and running the jobs page. So don’t be surprised if you start receiving emails from her for XenProject-related things. :-) Peace, -George Dunlap
[xen-unstable-coverity test] 162992: all pass - PUSHED
flight 162992 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/162992/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen c7691f5e340f3b579d40c77548f63133cdf5aac7 baseline version: xen 4bcf6433eed3d9cbc00865ec62380a33ca832dac Last test of basis 162857 2021-06-16 09:18:30 Z7 days Failing since162908 2021-06-20 09:18:24 Z3 days2 attempts Testing same since 162992 2021-06-23 09:20:40 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD George Dunlap Nick Rosbrook Nick Rosbrook Roger Pau Monné jobs: coverity-amd64 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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 4bcf6433ee..c7691f5e34 c7691f5e340f3b579d40c77548f63133cdf5aac7 -> coverity-tested/smoke
[ovmf test] 162987: regressions - FAIL
flight 162987 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162987/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 7471751a4d813a64501a9d7819b1eb405911b310 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 19 days Failing since162368 2021-06-04 15:42:59 Z 18 days 40 attempts Testing same since 162987 2021-06-23 05:52:05 Z0 days1 attempts People who touched revisions under test: Alexandru Elisei Ard Biesheuvel Daoxiang Li gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Maurice Ma Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 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 Not pushing. (No revision log; it would be 2284 lines long.)
[ovmf test] 162994: regressions - FAIL
flight 162994 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162994/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 7471751a4d813a64501a9d7819b1eb405911b310 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 19 days Failing since162368 2021-06-04 15:42:59 Z 18 days 41 attempts Testing same since 162987 2021-06-23 05:52:05 Z0 days2 attempts People who touched revisions under test: Alexandru Elisei Ard Biesheuvel Daoxiang Li gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Maurice Ma Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 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 Not pushing. (No revision log; it would be 2284 lines long.)
Re: Interrupt for port 19, but apparently not enabled; per-user 000000004af23acc
Hi Juergen,
On 22/06/2021 17:14, Juergen Gross wrote:
On 22.06.21 14:21, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4) in the evtchn driver:
[ 7.581000] [ cut here ]
[ 7.581899] Interrupt for port 19, but apparently not
enabled;
per-user 4af23acc
[ 7.583401] WARNING: CPU: 0 PID: 467 at
/home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:169
evtchn_interrupt+0xd5/0x100
[ 7.585583] Modules linked in:
[ 7.586188] CPU: 0 PID: 467 Comm: xenstore-read Not
tainted
5.13.0-rc6 #240
[ 7.587462] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 7.589462] RIP: e030:evtchn_interrupt+0xd5/0x100
[ 7.590361] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00
be 1d 00 00 00
e8 5f 72 c4 ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 03 5f 82 e8 6b 2d 96
ff <0f> 0b e9 4d ff ff ff 41 0f b6 f4 48 c7 c7 80 da a2 82 e8 f0
[ 7.593662] RSP: e02b:c90040003e60 EFLAGS: 00010082
[ 7.594636] RAX: RBX: 888102328c00 RCX:
0027
[ 7.595924] RDX: RSI: 88817fe18ad0 RDI:
88817fe18ad8
[ 7.597216] RBP: 888108ef8140 R08: R09:
0001
[ 7.598522] R10: R11: 7075727265746e49 R12:
[ 7.599810] R13: c90040003ec4 R14: 8881001b8000 R15:
888109b36f80
[ 7.601113] FS: () GS:88817fe0()
knlGS:
[ 7.602570] CS: 1e030 DS: ES: CR0:80050033
[ 7.603700] CR2: 7f15b390e368 CR3: 00010bb04000 CR4:
00050660
[ 7.604993] Call Trace:
[ 7.605501]
[ 7.605929] __handle_irq_event_percpu+0x4c/0x330
[ 7.606817] handle_irq_event_percpu+0x32/0xa0
[ 7.607670] handle_irq_event+0x3a/0x60
[ 7.608416] handle_edge_irq+0x9b/0x1f0
[ 7.609154] generic_handle_irq+0x4f/0x60
[ 7.609918] __evtchn_fifo_handle_events+0x195/0x3a0
[ 7.610864] __xen_evtchn_do_upcall+0x66/0xb0
[ 7.611693] __xen_pv_evtchn_do_upcall+0x1d/0x30
[ 7.612582] xen_pv_evtchn_do_upcall+0x9d/0xc0
[ 7.613439]
[ 7.613882] exc_xen_hypervisor_callback+0x8/0x10
This is quite similar to the problem I reported a few months ago (see
[1]) but this time this is happening with fifo rather than 2L.
I haven't been able to reproduced it reliably so far. But looking at
the code, I think I have found another potential race after commit
commit b6622798bc50b625a1e62f82c7190df40c1f5b21
Author: Juergen Gross
Date: Sat Mar 6 17:18:33 2021 +0100
xen/events: avoid handling the same event on two cpusat the same
time
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled
on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the
per-event data
and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Link:
https://lore.kernel.org/r/20210306161833.4552-4-jgr...@suse.com
Signed-off-by: Boris Ostrovsky
The evtchn driver will use the lateeoi handlers. So the code to ack
looks like:
do_mask(..., EVT_MASK_REASON_EOI_PENDING)
smp_store_release(&info->is_active, 0);
clear_evtchn(info->evtchn);
The code to handle an interrupts look like:
clear_link(...)
if ( evtchn_fifo_is_pending(port) && !evtchn_fifo_is_mask()) {
if (xchg_acquire(&info->is_active, 1)
return;
generic_handle_irq();
}
After changing the affinity, an interrupt may be received once on the
previous vCPU. So, I think the following can happen:
vCPU0 | vCPU1
|
Receive event |
| change affinity to vCPU1
clear_link() |
|
/* The interrupt is re-raised */
| receive event
|
| /* The interrupt is not masked */
info->is_active = 1 |
do_mask(...) |
info->is_active = 0 |
| info->is_active = 1
clear_evtchn(...) |
| do_mask(...)
| info->is_active = 0
| clear_evtchn(...)
Does this look plausible to you?
Yes, it does.
Thanks for the analysis.
So I guess for lateeoi events we need to clear is_active only in
xen_irq_lateeoi()? At a first glance this should fix the issue.
It should work and would be quite neat. But, I believe clear_evtchn()
would have to stick in the ack helper to avoid losing interrupts.
Could you try the attached patch, pl
[qemu-mainline test] 162969: regressions - FAIL
flight 162969 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162969/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass
[PATCH] xen/events: reset active flag for lateeoi events later
In order to avoid a race condition for user events when changing
cpu affinity reset the active flag only when EOI-ing the event.
This is working fine as all user events are lateeoi events. Note that
lateeoi_ack_mask_dynirq() is not modified as there is no explicit call
to xen_irq_lateeoi() expected later.
Reported-by: Julien Grall
Fixes: b6622798bc50b62 ("xen/events: avoid handling the same event on two cpus
at the same time")
Tested-by: Julien Grall
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_base.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 7bbfd58958bc..d7e361fb0548 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -642,6 +642,9 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
bool spurious)
}
info->eoi_time = 0;
+
+ /* is_active hasn't been reset yet, do it now. */
+ smp_store_release(&info->is_active, 0);
do_unmask(info, EVT_MASK_REASON_EOI_PENDING);
}
@@ -811,6 +814,7 @@ static void xen_evtchn_close(evtchn_port_t port)
BUG();
}
+/* Not called for lateeoi events. */
static void event_handler_exit(struct irq_info *info)
{
smp_store_release(&info->is_active, 0);
@@ -1883,7 +1887,12 @@ static void lateeoi_ack_dynirq(struct irq_data *data)
if (VALID_EVTCHN(evtchn)) {
do_mask(info, EVT_MASK_REASON_EOI_PENDING);
- event_handler_exit(info);
+ /*
+* Don't call event_handler_exit().
+* Need to keep is_active non-zero in order to ignore re-raised
+* events after cpu affinity changes while a lateeoi is pending.
+*/
+ clear_evtchn(evtchn);
}
}
--
2.26.2
[ovmf test] 162995: regressions - FAIL
flight 162995 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162995/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 7471751a4d813a64501a9d7819b1eb405911b310 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 19 days Failing since162368 2021-06-04 15:42:59 Z 18 days 42 attempts Testing same since 162987 2021-06-23 05:52:05 Z0 days3 attempts People who touched revisions under test: Alexandru Elisei Ard Biesheuvel Daoxiang Li gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Maurice Ma Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 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 Not pushing. (No revision log; it would be 2284 lines long.)
[linux-linus test] 162986: regressions - FAIL
flight 162986 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162986/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 19 guest-start.2 fail blocked in 152332 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-check
Re: smmuv1 breakage
Hi Stefano, > On 23 Jun 2021, at 9:09 am, Rahul Singh wrote: > > Hi Stefano, > >> On 22 Jun 2021, at 10:06 pm, Stefano Stabellini >> wrote: >> >> Hi Rahul, >> >> Do you have an opinion on how we should move forward on this? >> >> Do you think it is OK to go for a full revert of "xen/arm: smmuv1: >> Intelligent SMR allocation" or do you think it is best to go with an >> alternative fix? If so, do you have something in mind? >> > > Sorry for the late reply I was working on another high-priority task. > I will work on this will try to fix the issue. I will update you within 2-3 > days. I again checked my patches and found out that while allocating SMR I by mistake allocated one SMR for each SMMU device but we have to allocate the number of SMR based on supported stream matching register for each SMMU device. This might be causing the issue. As I don’t have any Xilinx hardware and on QEMU/Juno issue is not reproducible.Can you please test the attached patch and let me know if it works. Regards, Rahul > > Regards, > Rahul > >> >> >> On Tue, 15 Jun 2021, Stefano Stabellini wrote: >>> On Tue, 15 Jun 2021, Rahul Singh wrote: Hi Stefano > On 15 Jun 2021, at 3:21 am, Stefano Stabellini > wrote: > > Hi Rahul, > > Unfortunately, after bisecting, I discovered a few more breakages due to > your smmuv1 series (commits e889809b .. 3e6047ddf) on Xilinx ZynqMP. I > attached the DTB as reference. Please note that I made sure to > cherry-pick "xen/arm: smmuv1: Revert associating the group pointer with > the S2CR" during bisection. So the errors are present also on staging. > > The first breakage is an error at boot time in smmu.c#find_smmu_master, > see log1. I think it is due to the lack of ability to parse the new smmu > bindings in the old smmu driver. > > After removing all the "smmus" and "#stream-id-cells" properties in > device tree, I get past the previous error, everything seems to be OK at > early boot, but I actually get SMMU errors as soon as dom0 starting > using devices: > > (XEN) smmu: /smmu@fd80: Unexpected global fault, this could be serious > (XEN) smmu: /smmu@fd80: GFSR 0x8002, GFSYNR0 0x, > GFSYNR1 0x0877, GFSYNR2 0x This fault is "Unidentified stream fault” for StreamID “ 0x877” that means SMMU SMR is not configured for streamID “0x877" > [ 10.419681] macb ff0e.ethernet eth0: DMA bus error: HRESP not OK > [ 10.426452] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > Do you think you'll be able to help fix them? > > > You should be able to reproduce the two issues using Xilinx QEMU (but to > be honest I haven't tested it on QEMU yet, I was testing on real > hardware): > - clone and compile xilinx QEMU https://github.com/Xilinx/qemu.git > ./configure --target-list=aarch64-softmmu > make > - clone and build git://github.com/Xilinx/qemu-devicetrees.git > - use the attached script to run it > - kernel can be upstream defconfig 5.10 > I tried to reproduce the issue on Xilinx QEMU as per the steps shared above but I am not observing any issue on Xilinx QEMU. >>> >>> I tried on QEMU and it doesn't repro. I cannot explain why it works on >>> QEMU and it fails on real hardware. >>> >>> I also tested and confirmed on QEMU that SMMU is configured correctly for specifically StreamID “ 0x877” and for other streamIDs. I check the xen.dtb shared by you and found out the there is no "stream-id-cells” property in the master device but the "mmu-masters" property is present in the smmu node. For legacy smmu binding we need both "stream-id-cells” and "mmu-masters”. If you need to add the new smmu binding please add the "iommu-cells” property in the smmu node and the “iommus” property in the master device. >>> >>> In regards to the missing "stream-id-cells" property, I shared the wrong >>> dtb before, sorry. I was running a number of tests and I might have >>> picked the wrong file. The proper dtb comes with "stream-id-cells" for >>> the 0x877 device, see attached. >>> >>> >>> Can you please share the xen boot logs with me so that I can debug further why the error is observed? >>> >>> See attached. I did some debugging and discovered that it crashes while >>> accessing master->of_node in find_smmu_master. If I revert your series, >>> the crash goes away. It is very strange because your patches don't touch >>> find_smmu_master or insert_smmu_master directly. >>> >>> I did a git reset --hard on the commit "xen/arm: smmuv1: Add a stream >>> map entry iterator" and it worked, which points to "xen/arm: smmuv1: >>> Intelligent SMR allocation" being the problem, even if I have the revert >>> cherry-picked on top. Maybe the revert is not reverting enough? >>> >>> After this test, I switched bac
[xen-unstable test] 162971: regressions - FAIL
flight 162971 xen-unstable real [real] flight 163000 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162971/ http://logs.test-lab.xenproject.org/osstest/logs/163000/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 162533 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 162533 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 162533 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162533 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 162533 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 162533 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 162533 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 162533 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 162533 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 162533 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 162533 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 162533 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162533 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen 8af4b47f061edf6450f2b0a0a8134fdf1c13b3e5 baseline version: xen 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 Last test of basis 162533 2021-06-08 01:53:53 Z 15 days Failing since162556 2021-06-08 22:39:08 Z 14 days 21 attempts Testing same since 162885 2021-06-17 23:08:00 Z5 days
[qemu-mainline bisection] complete test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm testid guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 8af54b9172ff3b9bbdbb3191ed84994d275a0d81 Bug not present: cbde7be900d2a2279cbc4becb91d1ddd6a014def Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/161372/ commit 8af54b9172ff3b9bbdbb3191ed84994d275a0d81 Author: Daniel P. Berrangé Date: Mon Feb 22 12:54:55 2021 + machine: remove 'query-cpus' QMP command The newer 'query-cpus-fast' command avoids side effects on the guest execution. Note that some of the field names are different in the 'query-cpus-fast' command. Reviewed-by: Wainer dos Santos Moschetta Tested-by: Wainer dos Santos Moschetta Signed-off-by: Daniel P. Berrangé For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-debianhvm-i386-xsm.guest-saverestore.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-debianhvm-i386-xsm.guest-saverestore --summary-out=tmp/163001.bisection-summary --basis-template=152631 --blessings=real,real-bisect,real-retry qemu-mainline test-amd64-i386-xl-qemuu-debianhvm-i386-xsm guest-saverestore Searching for failure / basis pass: 162969 fail [host=chardonnay0] / 160125 [host=fiano1] 160119 [host=pinot1] 160113 [host=albana1] 160104 [host=albana0] 160097 [host=huxelrebe1] 160091 [host=elbling0] 160082 ok. Failure / basis pass flights: 162969 / 160082 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0add99ea3ea91af8230e3933ad7826b2da25a44d e3c30795823672eec9bde75187e184f23ed98d70 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 4751a48aeb2ab828b0a5cbdc585fd3642967cda1 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 6157b0e19721aadb4c7fdcfe57b2924af6144b14 b0d61ecef66eb05bd7a4eb7ada88ec5dab06dfee 14b95b3b8546db201e7efd0636ae0e215fae98f3 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/osstest/ovmf.git#4751a48aeb2ab828b0a5cbdc585fd3642967cda1-c410ad4da4b7785170d3d42a3ba190c2caac6feb git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c74\ 37ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://git.qemu.org/qemu.git#6157b0e19721aadb4c7fdcfe57b2924af6144b14-0add99ea3ea91af8230e3933ad7826b2da25a44d git://xenbits.xen.org/osstest/seabios.git#b0d61ecef66eb05bd7a4eb7ada88ec5dab06dfee-e3c30795823672eec9bde75187e184f23ed98d70 git://xenbits.xen.org/xen.git#14b95b3b8546db201e7efd0636ae0e215fae98f3-5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 Loaded 55584 nodes in revision graph Searching for test results: 162778 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 894fc4fd670aaf04a67dc7507739f914ff4bacf2 e3c30795823672eec9bde75187e184f23ed98d70 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 162795 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 894fc4fd670aaf04a67dc7507739f914ff4bacf2 e3c30795823672eec9bde75187e184f23ed98d70 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 162818 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 1ea06abceec61b6f3ab33dadb0510b6e09fb61e2 e3c30795823672eec
Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote: > > > On 6/18/2021 11:40 PM, Claire Chang wrote: > > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and > > use it to determine whether to bounce the data or not. This will be > > useful later to allow for different pools. > > > > Signed-off-by: Claire Chang > > Reviewed-by: Christoph Hellwig > > Tested-by: Stefano Stabellini > > Tested-by: Will Deacon > > Acked-by: Stefano Stabellini > > Reverting the rest of the series up to this patch fixed a boot crash with > NVMe on today's linux-next. Hmm, so that makes patch 7 the suspicious one, right? Looking at that one more closely, it looks like swiotlb_find_slots() takes 'alloc_size + offset' as its 'alloc_size' parameter from swiotlb_tbl_map_single() and initialises 'mem->slots[i].alloc_size' based on 'alloc_size + offset', which looks like a change in behaviour from the old code, which didn't include the offset there. swiotlb_release_slots() then adds the offset back on afaict, so we end up accounting for it twice and possibly unmap more than we're supposed to? Will
Re: Bug#989778: Regression in at least 5.10.y and mainline: Firewire audio interface fails to work properly (when booted under Xen)
Hi Robin,
On Mon, Jun 14, 2021 at 02:29:08PM +0100, Robin Murphy wrote:
> On 2021-06-13 07:29, Salvatore Bonaccorso wrote:
> > A user in Debian reported the above issue, which was reproducible with
> > 5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
> > ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") that
> > introduced the issue.
>
> Sounds like it's probably the same thing as being discussed over here:
>
> https://lore.kernel.org/linux-iommu/2e899de2-4b69-c4b6-33a6-09fb8949d...@nxp.com/
Thanks for the pointer, it seems that now it has been fixed upstream
with 5f89468e2f06 ("swiotlb: manipulate orig_addr when tlb_addr has
offset").
Regards,
Salvatore
[qemu-mainline bisection] complete test-amd64-amd64-xl-qemuu-ovmf-amd64
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qemuu-ovmf-amd64 testid guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 8af54b9172ff3b9bbdbb3191ed84994d275a0d81 Bug not present: cbde7be900d2a2279cbc4becb91d1ddd6a014def Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/161274/ commit 8af54b9172ff3b9bbdbb3191ed84994d275a0d81 Author: Daniel P. Berrangé Date: Mon Feb 22 12:54:55 2021 + machine: remove 'query-cpus' QMP command The newer 'query-cpus-fast' command avoids side effects on the guest execution. Note that some of the field names are different in the 'query-cpus-fast' command. Reviewed-by: Wainer dos Santos Moschetta Tested-by: Wainer dos Santos Moschetta Signed-off-by: Daniel P. Berrangé For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-xl-qemuu-ovmf-amd64.guest-saverestore.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-xl-qemuu-ovmf-amd64.guest-saverestore --summary-out=tmp/163006.bisection-summary --basis-template=152631 --blessings=real,real-bisect,real-retry qemu-mainline test-amd64-amd64-xl-qemuu-ovmf-amd64 guest-saverestore Searching for failure / basis pass: 162969 fail [host=pinot0] / 160125 [host=albana0] 160119 [host=godello1] 160113 [host=huxelrebe1] 160104 [host=fiano1] 160097 [host=pinot1] 160091 [host=godello0] 160088 [host=elbling0] 160082 [host=albana0] 160079 [host=albana1] 160070 [host=chardonnay1] 160066 [host=chardonnay0] 160002 [host=huxelrebe1] 159947 [host=godello0] 159926 [host=godello0] 159911 [host=fiano0] 159898 [host=albana0] 159888 [host=godello1] 159878 [host=godello0] 159869 [host=godello1] 159860 [host=albana1] 159853 [host\ =elbling1] 159848 [host=huxelrebe1] 159842 [host=elbling0] 159834 [host=godello0] 159828 ok. Failure / basis pass flights: 162969 / 159828 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0add99ea3ea91af8230e3933ad7826b2da25a44d e3c30795823672eec9bde75187e184f23ed98d70 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ef91b07388e1c0a50c604e5350eeda98428ccea6 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 cb90ecf9349198558569f6c86c4c27d215406095 ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e 243036df0d55673de59c214e240b9b914d278b65 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/osstest/ovmf.git#ef91b07388e1c0a50c604e5350eeda98428ccea6-c410ad4da4b7785170d3d42a3ba190c2caac6feb git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c74\ 37ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://git.qemu.org/qemu.git#cb90ecf9349198558569f6c86c4c27d215406095-0add99ea3ea91af8230e3933ad7826b2da25a44d git://xenbits.xen.org/osstest/seabios.git#ef88eeaf052c8a7d28c5f85e790c5e45bcffa45e-e3c30795823672eec9bde75187e184f23ed98d70 git://xenbits.xen.org/xen.git#243036df0d55673de59c214e240b9b914d278b65-5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 Loaded 55673 nodes in revision graph Searching for test results: 162778 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 894fc4fd670aaf04a67dc7507739f914ff4bacf2 e3c30795823672eec9bde75187e184f23ed98d70 5268b2dcf7e5342c8a51ceb4bed3e7740c69f5c1 162795 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c410ad4da4b7785170d3d42a3ba190c2caac6feb 3d273dd05e51e
Re: smmuv1 breakage
On Wed, 23 Jun 2021, Rahul Singh wrote: > Hi Stefano, > > > On 23 Jun 2021, at 9:09 am, Rahul Singh wrote: > > > > Hi Stefano, > > > >> On 22 Jun 2021, at 10:06 pm, Stefano Stabellini > >> wrote: > >> > >> Hi Rahul, > >> > >> Do you have an opinion on how we should move forward on this? > >> > >> Do you think it is OK to go for a full revert of "xen/arm: smmuv1: > >> Intelligent SMR allocation" or do you think it is best to go with an > >> alternative fix? If so, do you have something in mind? > >> > > > > Sorry for the late reply I was working on another high-priority task. > > I will work on this will try to fix the issue. I will update you within 2-3 > > days. > > I again checked my patches and found out that while allocating SMR I by > mistake > allocated one SMR for each SMMU device but we have to allocate the number of > SMR based on supported stream matching register for each SMMU device. > > This might be causing the issue. As I don’t have any Xilinx hardware and on > QEMU/Juno issue is not reproducible.Can you please test the attached patch and > let me know if it works. Yes this solves the issue for me, thank you!! Acked-by: Stefano Stabellini Tested-by: Stefano Stabellini > > > > Regards, > > Rahul > > > >> > >> > >> On Tue, 15 Jun 2021, Stefano Stabellini wrote: > >>> On Tue, 15 Jun 2021, Rahul Singh wrote: > Hi Stefano > > > On 15 Jun 2021, at 3:21 am, Stefano Stabellini > > wrote: > > > > Hi Rahul, > > > > Unfortunately, after bisecting, I discovered a few more breakages due to > > your smmuv1 series (commits e889809b .. 3e6047ddf) on Xilinx ZynqMP. I > > attached the DTB as reference. Please note that I made sure to > > cherry-pick "xen/arm: smmuv1: Revert associating the group pointer with > > the S2CR" during bisection. So the errors are present also on staging. > > > > The first breakage is an error at boot time in smmu.c#find_smmu_master, > > see log1. I think it is due to the lack of ability to parse the new smmu > > bindings in the old smmu driver. > > > > After removing all the "smmus" and "#stream-id-cells" properties in > > device tree, I get past the previous error, everything seems to be OK at > > early boot, but I actually get SMMU errors as soon as dom0 starting > > using devices: > > > > (XEN) smmu: /smmu@fd80: Unexpected global fault, this could be > > serious > > (XEN) smmu: /smmu@fd80: GFSR 0x8002, GFSYNR0 0x, > > GFSYNR1 0x0877, GFSYNR2 0x > > This fault is "Unidentified stream fault” for StreamID “ 0x877” that > means SMMU SMR is not configured for streamID “0x877" > > > > [ 10.419681] macb ff0e.ethernet eth0: DMA bus error: HRESP not OK > > [ 10.426452] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > Do you think you'll be able to help fix them? > > > > > > You should be able to reproduce the two issues using Xilinx QEMU (but to > > be honest I haven't tested it on QEMU yet, I was testing on real > > hardware): > > - clone and compile xilinx QEMU https://github.com/Xilinx/qemu.git > > ./configure --target-list=aarch64-softmmu > > make > > - clone and build git://github.com/Xilinx/qemu-devicetrees.git > > - use the attached script to run it > > - kernel can be upstream defconfig 5.10 > > > > I tried to reproduce the issue on Xilinx QEMU as per the steps shared > above > but I am not observing any issue on Xilinx QEMU. > >>> > >>> I tried on QEMU and it doesn't repro. I cannot explain why it works on > >>> QEMU and it fails on real hardware. > >>> > >>> > I also tested and confirmed on QEMU that SMMU is configured correctly > for specifically StreamID “ 0x877” and for other streamIDs. > > I check the xen.dtb shared by you and found out the there is no > "stream-id-cells” > property in the master device but the "mmu-masters" property is present > in the > smmu node. For legacy smmu binding we need both "stream-id-cells” and > "mmu-masters”. > If you need to add the new smmu binding please add the "iommu-cells” > property in the smmu node and the “iommus” property in the master device. > >>> > >>> In regards to the missing "stream-id-cells" property, I shared the wrong > >>> dtb before, sorry. I was running a number of tests and I might have > >>> picked the wrong file. The proper dtb comes with "stream-id-cells" for > >>> the 0x877 device, see attached. > >>> > >>> > >>> > Can you please share the xen boot logs with me so that I can debug > further why the error is observed? > >>> > >>> See attached. I did some debugging and discovered that it crashes while > >>> accessing master->of_node in find_smmu_master. If I revert your series, > >>> the crash goes away. It is very strange because your patches don't touch > >
[qemu-mainline test] 162996: regressions - FAIL
flight 162996 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162996/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail 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-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass
Re: [PATCH v6 6/9] docs: add doxygen preprocessor and related files
On Mon, 10 May 2021, Luca Fancellu wrote:
> Add preprocessor called by doxygen before parsing headers,
> it will include in every header a doxygen_include.h file
> that provides missing defines and includes that are
> usually passed by the compiler.
>
> Add doxy_input.list that is a text file containing the
> relative path to the source code file to be parsed by
> doxygen. The path sould be relative to the xen folder:
> E.g. xen/include/public/grant_table.h
>
> Signed-off-by: Luca Fancellu
> ---
> docs/xen-doxygen/doxy-preprocessor.py | 110 ++
> docs/xen-doxygen/doxy_input.list | 0
> docs/xen-doxygen/doxygen_include.h.in | 32
> 3 files changed, 142 insertions(+)
> create mode 100755 docs/xen-doxygen/doxy-preprocessor.py
> create mode 100644 docs/xen-doxygen/doxy_input.list
> create mode 100644 docs/xen-doxygen/doxygen_include.h.in
>
> diff --git a/docs/xen-doxygen/doxy-preprocessor.py
> b/docs/xen-doxygen/doxy-preprocessor.py
> new file mode 100755
> index 00..496899d8e6
> --- /dev/null
> +++ b/docs/xen-doxygen/doxy-preprocessor.py
> @@ -0,0 +1,110 @@
> +#!/usr/bin/python3
> +#
> +# Copyright (c) 2021, Arm Limited.
> +#
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +
> +import os, sys, re
> +
> +
> +# Variables that holds the preprocessed header text
> +output_text = ""
> +header_file_name = ""
> +
> +# Variables to enumerate the anonymous structs/unions
> +anonymous_struct_count = 0
> +anonymous_union_count = 0
> +
> +
> +def error(text):
> +sys.stderr.write("{}\n".format(text))
> +sys.exit(1)
> +
> +
> +def write_to_output(text):
> +sys.stdout.write(text)
> +
> +
> +def insert_doxygen_header(text):
> +# Here the strategy is to insert the #include in the
> +# first line of the header
> +abspath = os.path.dirname(os.path.abspath(__file__))
> +text += "#include \"{}/doxygen_include.h\"\n".format(abspath)
> +
> +return text
> +
> +
> +def enumerate_anonymous(match):
> +global anonymous_struct_count
> +global anonymous_union_count
> +
> +if "struct" in match.group(1):
> +label = "anonymous_struct_%d" % anonymous_struct_count
> +anonymous_struct_count += 1
> +else:
> +label = "anonymous_union_%d" % anonymous_union_count
> +anonymous_union_count += 1
> +
> +return match.group(1) + " " + label + " {"
> +
> +
> +def manage_anonymous_structs_unions(text):
> +# Match anonymous unions/structs with this pattern:
> +# struct/union {
> +# [...]
> +#
> +# and substitute it in this way:
> +#
> +# struct anonymous_struct_# {
> +# [...]
> +# or
> +# union anonymous_union_# {
> +# [...]
> +# where # is a counter starting from zero, different between structs and
> +# unions
> +#
> +# We don't count anonymous union/struct that are part of a typedef
> because
> +# they don't create any issue for doxygen
> +text = re.sub(
> +"(? +enumerate_anonymous,
> +text,
> +flags=re.S
> +)
My python is a bit rusty but I thought this is really clever!
One question: given that anonymous_struct_count is local per file being
processed, it always starts at 0 for each header. I think that is
actually better from a documentation readability point of view.
However, is it possible that Doxygen gets confused in a case where we
can multiple "struct anonymous_struct_0", e.g. one for grant_table.h,
one for event_channel.h, etc. ?
Re: [PATCH] xen/events: reset active flag for lateeoi events later
On 6/23/21 9:09 AM, Juergen Gross wrote:
> In order to avoid a race condition for user events when changing
> cpu affinity reset the active flag only when EOI-ing the event.
>
> This is working fine as all user events are lateeoi events. Note that
> lateeoi_ack_mask_dynirq() is not modified as there is no explicit call
> to xen_irq_lateeoi() expected later.
>
> Reported-by: Julien Grall
> Fixes: b6622798bc50b62 ("xen/events: avoid handling the same event on two
> cpus at the same time")
> Tested-by: Julien Grall
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
[ovmf test] 162999: regressions - FAIL
flight 162999 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162999/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 7471751a4d813a64501a9d7819b1eb405911b310 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 19 days Failing since162368 2021-06-04 15:42:59 Z 19 days 43 attempts Testing same since 162987 2021-06-23 05:52:05 Z0 days4 attempts People who touched revisions under test: Alexandru Elisei Ard Biesheuvel Daoxiang Li gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Maurice Ma Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 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 Not pushing. (No revision log; it would be 2284 lines long.)
Re: [PATCH v6 7/9] docs: Change Makefile and sphinx configuration for doxygen
On Mon, 10 May 2021, Luca Fancellu wrote:
> Modify docs/Makefile to call doxygen and generate sphinx
> html documentation given the doxygen XML output.
>
> Modify docs/conf.py sphinx configuration file to setup
> the breathe extension that works as bridge between
> sphinx and doxygen.
>
> Add some files to the .gitignore to ignore some
> generated files for doxygen.
>
> Signed-off-by: Luca Fancellu
> ---
> .gitignore| 6 ++
> docs/Makefile | 42 +++---
> docs/conf.py | 48 +---
> 3 files changed, 90 insertions(+), 6 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 1c2fa1530b..d271e0ce6a 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -58,6 +58,12 @@ docs/man7/
> docs/man8/
> docs/pdf/
> docs/txt/
> +docs/doxygen-output
> +docs/sphinx
> +docs/xen.doxyfile
> +docs/xen.doxyfile.tmp
> +docs/xen-doxygen/doxygen_include.h
> +docs/xen-doxygen/doxygen_include.h.tmp
> extras/mini-os*
> install/*
> stubdom/*-minios-config.mk
> diff --git a/docs/Makefile b/docs/Makefile
> index 8de1efb6f5..2f784c36ce 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -17,6 +17,18 @@ TXTSRC-y := $(sort $(shell find misc -name '*.txt' -print))
>
> PANDOCSRC-y := $(sort $(shell find designs/ features/ misc/ process/ specs/
> \( -name '*.pandoc' -o -name '*.md' \) -print))
>
> +# Directory in which the doxygen documentation is created
> +# This must be kept in sync with breathe_projects value in conf.py
> +DOXYGEN_OUTPUT = doxygen-output
> +
> +# Doxygen input headers from xen-doxygen/doxy_input.list file
> +DOXY_LIST_SOURCES != cat "xen-doxygen/doxy_input.list"
> +DOXY_LIST_SOURCES := $(realpath $(addprefix
> $(XEN_ROOT)/,$(DOXY_LIST_SOURCES)))
I cannot find exactly who is populating doxy_input.list. I can see it is
empty in patch #6. Does it get populated during the build?
> +DOXY_DEPS := xen.doxyfile \
> + xen-doxygen/mainpage.md \
> + xen-doxygen/doxygen_include.h
> +
> # Documentation targets
> $(foreach i,$(MAN_SECTIONS), \
>$(eval DOC_MAN$(i) := $(patsubst man/%.$(i),man$(i)/%.$(i), \
> @@ -46,8 +58,28 @@ all: build
> build: html txt pdf man-pages figs
>
> .PHONY: sphinx-html
> -sphinx-html:
> - sphinx-build -b html . sphinx/html
> +sphinx-html: $(DOXY_DEPS) $(DOXY_LIST_SOURCES)
> +ifneq ($(SPHINXBUILD),no)
This check on SPHINXBUILD is new, it wasn't there before. Why do we need
it now? We are not really changing anything in regards to Sphinx, just
adding Doxygen support. Or was it a mistake that it was missing even
before this patch?
> + $(DOXYGEN) xen.doxyfile
> + XEN_ROOT=$(realpath $(XEN_ROOT)) $(SPHINXBUILD) -b html . sphinx/html
> +else
> + @echo "Sphinx is not installed; skipping sphinx-html documentation."
> +endif
> +
> +xen.doxyfile: xen.doxyfile.in xen-doxygen/doxy_input.list
> + @echo "Generating $@"
> + @sed -e "s,@XEN_BASE@,$(realpath $(XEN_ROOT)),g" $< \
> + | sed -e "s,@DOXY_OUT@,$(DOXYGEN_OUTPUT),g" > $@.tmp
> + @$(foreach inc,\
> + $(DOXY_LIST_SOURCES),\
> + echo "INPUT += \"$(inc)\"" >> $@.tmp; \
> + )
> + mv $@.tmp $@
> +
> +xen-doxygen/doxygen_include.h: xen-doxygen/doxygen_include.h.in
> + @echo "Generating $@"
> + @sed -e "s,@XEN_BASE@,$(realpath $(XEN_ROOT)),g" $< > $@.tmp
> + @mv $@.tmp $@
Is the absolute path required? If not, we can probably get rid of this
generation step and simply have the relative path in
xen-doxygen/doxygen_include.h. I think this could apply to
xen.doxyfile.in above.
> .PHONY: html
> html: $(DOC_HTML) html/index.html
> @@ -71,7 +103,11 @@ clean: clean-man-pages
> $(MAKE) -C figs clean
> rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
> rm -rf *.ilg *.log *.ind *.toc *.bak *.tmp core
> - rm -rf html txt pdf sphinx/html
> + rm -rf html txt pdf sphinx $(DOXYGEN_OUTPUT)
> + rm -f xen.doxyfile
> + rm -f xen.doxyfile.tmp
> + rm -f xen-doxygen/doxygen_include.h
> + rm -f xen-doxygen/doxygen_include.h.tmp
>
> .PHONY: distclean
> distclean: clean
> diff --git a/docs/conf.py b/docs/conf.py
> index 50e41501db..a48de42331 100644
> --- a/docs/conf.py
> +++ b/docs/conf.py
> @@ -13,13 +13,17 @@
> # add these directories to sys.path here. If the directory is relative to the
> # documentation root, use os.path.abspath to make it absolute, like shown
> here.
> #
> -# import os
> -# import sys
> +import os
> +import sys
> # sys.path.insert(0, os.path.abspath('.'))
>
>
> # -- Project information
> -
>
> +if "XEN_ROOT" not in os.environ:
> +sys.exit("$XEN_ROOT environment variable undefined.")
> +XEN_ROOT = os.path.abspath(os.environ["XEN_ROOT"])
> +
> project = u'Xen'
> copyright = u'2019, The Xen development community'
> author = u'The Xen development community'
> @@ -35,6 +39,7 @@ try:
> xe
Re: [PATCH v6 8/9] docs: hypercalls sphinx skeleton for generated html
On Mon, 10 May 2021, Luca Fancellu wrote: > Create a skeleton for the documentation about hypercalls > > Signed-off-by: Luca Fancellu > --- > v6 changes: > - Now every platform has the same sections in .rst files > --- > .gitignore | 1 + > docs/Makefile | 4 > docs/hypercall-interfaces/arm32.rst| 32 ++ > docs/hypercall-interfaces/arm64.rst| 32 ++ > docs/hypercall-interfaces/index.rst.in | 7 ++ > docs/hypercall-interfaces/x86_64.rst | 32 ++ > docs/index.rst | 8 +++ > 7 files changed, 116 insertions(+) > create mode 100644 docs/hypercall-interfaces/arm32.rst > create mode 100644 docs/hypercall-interfaces/arm64.rst > create mode 100644 docs/hypercall-interfaces/index.rst.in > create mode 100644 docs/hypercall-interfaces/x86_64.rst > > diff --git a/.gitignore b/.gitignore > index d271e0ce6a..a9aab120ae 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -64,6 +64,7 @@ docs/xen.doxyfile > docs/xen.doxyfile.tmp > docs/xen-doxygen/doxygen_include.h > docs/xen-doxygen/doxygen_include.h.tmp > +docs/hypercall-interfaces/index.rst > extras/mini-os* > install/* > stubdom/*-minios-config.mk > diff --git a/docs/Makefile b/docs/Makefile > index 2f784c36ce..b02c3dfb79 100644 > --- a/docs/Makefile > +++ b/docs/Makefile > @@ -61,6 +61,9 @@ build: html txt pdf man-pages figs > sphinx-html: $(DOXY_DEPS) $(DOXY_LIST_SOURCES) > ifneq ($(SPHINXBUILD),no) > $(DOXYGEN) xen.doxyfile > + @echo "Generating hypercall-interfaces/index.rst" > + @sed -e "s,@XEN_TARGET_ARCH@,$(XEN_TARGET_ARCH),g" \ > + hypercall-interfaces/index.rst.in > > hypercall-interfaces/index.rst I take that this means we are going to generate docs only for the architecture that we are building? So if we build for x86, then the docs are for x86 (no arm32 and arm64 docs.) Is that right? Is that because Doxygen relies somehow on the compiler to extract data? I am asking because if Doxygen doesn't rely on the compiler, then it could probably generate the docs for all architectures in one go? > XEN_ROOT=$(realpath $(XEN_ROOT)) $(SPHINXBUILD) -b html . sphinx/html > else > @echo "Sphinx is not installed; skipping sphinx-html documentation." > @@ -108,6 +111,7 @@ clean: clean-man-pages > rm -f xen.doxyfile.tmp > rm -f xen-doxygen/doxygen_include.h > rm -f xen-doxygen/doxygen_include.h.tmp > + rm -f hypercall-interfaces/index.rst > > .PHONY: distclean > distclean: clean > diff --git a/docs/hypercall-interfaces/arm32.rst > b/docs/hypercall-interfaces/arm32.rst > new file mode 100644 > index 00..6762d9fc7c > --- /dev/null > +++ b/docs/hypercall-interfaces/arm32.rst > @@ -0,0 +1,32 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Hypercall Interfaces - arm32 > + > + > +Starting points > +--- > +.. toctree:: > + :maxdepth: 2 > + > + > + > +Functions > +- > + > + > +Structs > +--- > + > + > +Enums and sets of #defines > +-- > + > + > +Typedefs > + > + > + > +Enum values and individual #defines > +--- > + > + > diff --git a/docs/hypercall-interfaces/arm64.rst > b/docs/hypercall-interfaces/arm64.rst > new file mode 100644 > index 00..5e701a2adc > --- /dev/null > +++ b/docs/hypercall-interfaces/arm64.rst > @@ -0,0 +1,32 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Hypercall Interfaces - arm64 > + > + > +Starting points > +--- > +.. toctree:: > + :maxdepth: 2 > + > + > + > +Functions > +- > + > + > +Structs > +--- > + > + > +Enums and sets of #defines > +-- > + > + > +Typedefs > + > + > + > +Enum values and individual #defines > +--- > + > + > diff --git a/docs/hypercall-interfaces/index.rst.in > b/docs/hypercall-interfaces/index.rst.in > new file mode 100644 > index 00..e4dcc5db8d > --- /dev/null > +++ b/docs/hypercall-interfaces/index.rst.in > @@ -0,0 +1,7 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Hypercall Interfaces > + > + > +.. toctree:: > + @XEN_TARGET_ARCH@ > diff --git a/docs/hypercall-interfaces/x86_64.rst > b/docs/hypercall-interfaces/x86_64.rst > new file mode 100644 > index 00..59e948900c > --- /dev/null > +++ b/docs/hypercall-interfaces/x86_64.rst > @@ -0,0 +1,32 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Hypercall Interfaces - x86_64 > += > + > +Starting points > +--- > +.. toctree:: > + :maxdepth: 2 > + > + > + > +Functions > +- > + > + > +Structs > +--- > + > + > +Enums and sets of #defines > +-- > + > + > +Typedefs > + > + > + > +Enum values and individual #defines > +---
Re: [PATCH v6 9/9] docs/doxygen: doxygen documentation for grant_table.h
On Mon, 10 May 2021, Luca Fancellu wrote: > Modification to include/public/grant_table.h: > > 1) Add doxygen tags to: > - Create Grant tables section > - include variables in the generated documentation > - Used @keepindent/@endkeepindent to enclose comment >section that are indented using spaces, to keep >the indentation. > 2) Add .rst file for grant table for Arm64 Why only arm64? > Signed-off-by: Luca Fancellu > --- > v6 changes: > - Fix misaligned comment > - Moved comments to make them display in the docs > - Included more documentation in the docs > (see output here: > https://luca.fancellu.gitlab.io/xen-docs/hypercall-interfaces/common/grant_tables.html) It looks much much better. All the info we care about seems to be there. The only things that I noticed missing and might be good to keep is the small comment about HYPERVISOR_grant_table_op: /* ` enum neg_errnoval * ` HYPERVISOR_grant_table_op(enum grant_table_op cmd, * ` void *args, * ` unsigned int count) * ` * * @args points to an array of a per-command data structure. The array * has @count members All the changes look good to me. > v5 changes: > - Move GNTCOPY_* define next to the flags field > v4 changes: > - Used @keepindent/@endkeepindent doxygen commands > to keep text with spaces indentation. > - drop changes to grant_entry_v1 comment, it will > be changed and included in the docs in a future patch > - Move docs .rst to "common" folder > v3 changes: > - removed tags to skip anonymous union/struct > - moved back comment pointed out by Jan > - moved down defines related to struct gnttab_copy > as pointed out by Jan > v2 changes: > - Revert back to anonymous union/struct > - add doxygen tags to skip anonymous union/struct > --- > docs/hypercall-interfaces/arm64.rst | 1 + > .../common/grant_tables.rst | 9 + > docs/xen-doxygen/doxy_input.list | 1 + > xen/include/public/grant_table.h | 387 +++--- > 4 files changed, 245 insertions(+), 153 deletions(-) > create mode 100644 docs/hypercall-interfaces/common/grant_tables.rst > > diff --git a/docs/hypercall-interfaces/arm64.rst > b/docs/hypercall-interfaces/arm64.rst > index 5e701a2adc..cb4c0d13de 100644 > --- a/docs/hypercall-interfaces/arm64.rst > +++ b/docs/hypercall-interfaces/arm64.rst > @@ -8,6 +8,7 @@ Starting points > .. toctree:: > :maxdepth: 2 > > + common/grant_tables > > > Functions > diff --git a/docs/hypercall-interfaces/common/grant_tables.rst > b/docs/hypercall-interfaces/common/grant_tables.rst > new file mode 100644 > index 00..b8a1ef8759 > --- /dev/null > +++ b/docs/hypercall-interfaces/common/grant_tables.rst > @@ -0,0 +1,9 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Grant Tables > + > + > +.. doxygengroup:: grant_table > + :project: Xen > + :members: > + :undoc-members: > diff --git a/docs/xen-doxygen/doxy_input.list > b/docs/xen-doxygen/doxy_input.list > index e69de29bb2..233d692fa7 100644 > --- a/docs/xen-doxygen/doxy_input.list > +++ b/docs/xen-doxygen/doxy_input.list > @@ -0,0 +1 @@ > +xen/include/public/grant_table.h > diff --git a/xen/include/public/grant_table.h > b/xen/include/public/grant_table.h > index 84b1d26b36..dfa5155927 100644 > --- a/xen/include/public/grant_table.h > +++ b/xen/include/public/grant_table.h > @@ -25,15 +25,19 @@ > * Copyright (c) 2004, K A Fraser > */ > > +/** > + * @file > + * @brief Interface for granting foreign access to page frames, and receiving > + * page-ownership transfers. > + */ > + > #ifndef __XEN_PUBLIC_GRANT_TABLE_H__ > #define __XEN_PUBLIC_GRANT_TABLE_H__ > > #include "xen.h" > > -/* > - * `incontents 150 gnttab Grant Tables > - * > - * Xen's grant tables provide a generic mechanism to memory sharing > +/** > + * @brief Xen's grant tables provide a generic mechanism to memory sharing > * between domains. This shared memory interface underpins the split > * device drivers for block and network IO. > * > @@ -51,13 +55,13 @@ > * know the real machine address of a page it is sharing. This makes > * it possible to share memory correctly with domains running in > * fully virtualised memory. > - */ > - > -/*** > + * > * GRANT TABLE REPRESENTATION > - */ > - > -/* Some rough guidelines on accessing and updating grant-table entries > + * > + * A grant table comprises a packed array of grant entries in one or more > + * page frames shared between Xen and a guest. > + * > + * Some rough guidelines on accessing and updating grant-table entries > * in a concurrency-safe manner. For more information, Linux contains a > * reference implementation for guest OSes (drivers/xen/grant_table.c, see > * > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/xen/grant-table.c;hb=HEAD > @@ -66,6 +70,7 @@ > * compiler barrier will still be requir
[linux-5.4 test] 162998: tolerable FAIL - PUSHED
flight 162998 linux-5.4 real [real] flight 163008 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162998/ http://logs.test-lab.xenproject.org/osstest/logs/163008/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 12 debian-di-install fail pass in 163008-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 163008 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 163008 never pass test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162890 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 162890 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 162890 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 162890 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 162890 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 162890 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 162890 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 162890 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162890 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 162890 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 162890 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linux4037804c55745738e0950658a5132790e6ac52e4 baseline version: linuxa82d4d5e9fe6e6448fb5885a184460864c2f14a5 Last test of basis 162890 2021-06-18 08:12:38 Z5 days Testing same since 162998 2021-06-23 13:11:21 Z0 days1 attempts People who touched revisions under test: afzal mohammed Aleksander Jan Bajkowski Alex Deucher
[linux-linus test] 163003: regressions - FAIL
flight 163003 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/163003/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 14 guest-startfail in 162986 REGR. vs. 152332 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-credit1 13 debian-fixup fail pass in 162986 test-amd64-amd64-examine 4 memdisk-try-append fail pass in 162986 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 162986 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 20 guest-start/debianhvm.repeat fail pass in 162986 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 19 guest-start.2 fail in 162986 blocked in 152332 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail
Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On 6/18/2021 11:40 PM, Claire Chang wrote: > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and > use it to determine whether to bounce the data or not. This will be > useful later to allow for different pools. > > Signed-off-by: Claire Chang > Reviewed-by: Christoph Hellwig > Tested-by: Stefano Stabellini > Tested-by: Will Deacon > Acked-by: Stefano Stabellini Reverting the rest of the series up to this patch fixed a boot crash with NVMe on today's linux-next. [ 22.286574][T7] Unable to handle kernel paging request at virtual address dfff800e [ 22.295225][T7] Mem abort info: [ 22.298743][T7] ESR = 0x9604 [ 22.302496][T7] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.308525][T7] SET = 0, FnV = 0 [ 22.312274][T7] EA = 0, S1PTW = 0 [ 22.316131][T7] FSC = 0x04: level 0 translation fault [ 22.321704][T7] Data abort info: [ 22.325278][T7] ISV = 0, ISS = 0x0004 [ 22.329840][T7] CM = 0, WnR = 0 [ 22.333503][T7] [dfff800e] address between user and kernel address ranges [ 22.338543][ T256] igb 0006:01:00.0: Intel(R) Gigabit Ethernet Network Connection [ 22.341400][T7] Internal error: Oops: 9604 [#1] SMP [ 22.348915][ T256] igb 0006:01:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 4c:38:d5:09:c8:83 [ 22.354458][T7] Modules linked in: igb(+) i2c_algo_bit nvme mlx5_core(+) i2c_core nvme_core firmware_class [ 22.362512][ T256] igb 0006:01:00.0: eth0: PBA No: G69016-004 [ 22.372287][T7] CPU: 13 PID: 7 Comm: kworker/u64:0 Not tainted 5.13.0-rc7-next-20210623+ #47 [ 22.372293][T7] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 1.6 06/28/2020 [ 22.372298][T7] Workqueue: nvme-reset-wq nvme_reset_work [nvme] [ 22.378145][ T256] igb 0006:01:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s) [ 22.386901][T7] [ 22.386905][T7] pstate: 1005 (nzcV daif -PAN -UAO -TCO BTYPE=--) [ 22.386910][T7] pc : dma_direct_map_sg+0x304/0x8f0 is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119 (inlined by) dma_direct_map_page at /usr/src/linux-next/kernel/dma/direct.h:90 (inlined by) dma_direct_map_sg at /usr/src/linux-next/kernel/dma/direct.c:428 [ 22.386919][T7] lr : dma_map_sg_attrs+0x6c/0x118 [ 22.386924][T7] sp : 80001dc8eac0 [ 22.386926][T7] x29: 80001dc8eac0 x28: 199e70b0 x27: [ 22.386935][T7] x26: 000847ee7000 x25: 80001158e570 x24: 0002 [ 22.386943][T7] x23: dfff8000 x22: 0100 x21: 199e7460 [ 22.386951][T7] x20: 199e7488 x19: 0001 x18: 10062670 [ 22.386955][ T253] Unable to handle kernel paging request at virtual address dfff800e [ 22.386958][T7] x17: 8000109f6a90 x16: 8000109e1b4c x15: 89303420 [ 22.386965][ T253] Mem abort info: [ 22.386967][T7] x14: 0001 x13: 80001158e000 [ 22.386970][ T253] ESR = 0x9604 [ 22.386972][T7] x12: 1fffe00108fdce01 [ 22.386975][ T253] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.386976][T7] x11: 1fffe00108fdce03 x10: 000847ee700c x9 : 0004 [ 22.386981][ T253] SET = 0, FnV = 0 [ 22.386983][T7] [ 22.386985][T7] x8 : 73b91d72 [ 22.386986][ T253] EA = 0, S1PTW = 0 [ 22.386987][T7] x7 : x6 : 000e [ 22.386990][ T253] FSC = 0x04: level 0 translation fault [ 22.386992][T7] [ 22.386994][T7] x5 : dfff8000 [ 22.386995][ T253] Data abort info: [ 22.386997][T7] x4 : 0008c7ede000 [ 22.386999][ T253] ISV = 0, ISS = 0x0004 [ 22.386999][T7] x3 : 0008c7ede000 [ 22.387003][T7] x2 : 1000 [ 22.387003][ T253] CM = 0, WnR = 0 [ 22.387006][T7] x1 : x0 : 0071 [ 22.387008][ T253] [dfff800e] address between user and kernel address ranges [ 22.387011][T7] [ 22.387013][T7] Call trace: [ 22.387016][T7] dma_direct_map_sg+0x304/0x8f0 [ 22.387022][T7] dma_map_sg_attrs+0x6c/0x118 [ 22.387026][T7] nvme_map_data+0x2ec/0x21d8 [nvme] [ 22.387040][T7] nvme_queue_rq+0x274/0x3f0 [nvme] [ 22.387052][T7] blk_mq_dispatch_rq_list+0x2ec/0x18a0 [ 22.387060][T7] __blk_mq_sched_dispatch_requests+0x2a0/0x3e8 [ 22.387065][T7] blk_mq_sched_dispatch_requests+0xa4/0x100 [ 22.387070][T7] __blk_mq_run_hw_queue+0x148/0x1d8 [ 22.387075][T7] __blk_mq_delay_run_hw_queue+0x3f8/0x730 [ 22.414539][ T269] igb 0006:01:00.0 enP6p1s0: renamed from eth0 [ 22.418957][T7] blk_mq_run_hw_queue+0x148/0x248 [ 22.418969][T7] blk_mq_sched_insert_request+0x2a4/0x330 [ 22.418975][T7] blk_execute_rq_nowait+0xc8/0x118 [ 22.418981][T7] blk_execute_
Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, Claire Chang wrote:
>>> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
>>> use it to determine whether to bounce the data or not. This will be
>>> useful later to allow for different pools.
>>>
>>> Signed-off-by: Claire Chang
>>> Reviewed-by: Christoph Hellwig
>>> Tested-by: Stefano Stabellini
>>> Tested-by: Will Deacon
>>> Acked-by: Stefano Stabellini
>>
>> Reverting the rest of the series up to this patch fixed a boot crash with
>> NVMe on today's linux-next.
>
> Hmm, so that makes patch 7 the suspicious one, right?
Will, no. It is rather patch #6 (this patch). Only the patch from #6 to #12
were reverted to fix the issue. Also, looking at this offset of the crash,
pc : dma_direct_map_sg+0x304/0x8f0
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced in this patch here.
+static inline bool is_swiotlb_force_bounce(struct device *dev)
+{
+ return dev->dma_io_tlb_mem->force_bounce;
+}
>
> Looking at that one more closely, it looks like swiotlb_find_slots() takes
> 'alloc_size + offset' as its 'alloc_size' parameter from
> swiotlb_tbl_map_single() and initialises 'mem->slots[i].alloc_size' based
> on 'alloc_size + offset', which looks like a change in behaviour from the
> old code, which didn't include the offset there.
>
> swiotlb_release_slots() then adds the offset back on afaict, so we end up
> accounting for it twice and possibly unmap more than we're supposed to?
>
> Will
>
RE: [PATCH 3/9] VT-d: undo device mappings upon error
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:28 PM
>
> When
> - flushes (supposedly not possible anymore after XSA-373),
> - secondary mappings for legacy PCI devices behind bridges,
> - secondary mappings for chipset quirks, or
> - find_upstream_bridge() invocations
> fail, the successfully established device mappings should not be left
> around.
>
> Further, when (parts of) unmapping fail, simply returning an error is
> typically not enough. Crash the domain instead in such cases, arranging
> for domain cleanup to continue in a best effort manner despite such
> failures.
>
> Finally make domain_context_unmap()'s error behavior consistent in the
> legacy PCI device case: Don't bail from the function in one special
> case, but always just exit the switch statement.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Paul Durrant
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1442,9 +1442,15 @@ int domain_context_mapping_one(
> if ( !seg && !rc )
> rc = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
>
> +if ( rc )
> +domain_context_unmap_one(domain, iommu, bus, devfn);
> +
> return rc;
> }
>
> +static int domain_context_unmap(struct domain *d, uint8_t devfn,
> +struct pci_dev *pdev);
> +
> static int domain_context_mapping(struct domain *domain, u8 devfn,
>struct pci_dev *pdev)
> {
> @@ -1505,16 +1511,21 @@ static int domain_context_mapping(struct
> if ( ret )
> break;
>
> -if ( find_upstream_bridge(seg, &bus, &devfn, &secbus) < 1 )
> -break;
> +if ( (ret = find_upstream_bridge(seg, &bus, &devfn, &secbus)) < 1 )
> +{
> +if ( !ret )
> +break;
> +ret = -ENXIO;
> +}
>
> /*
> * Mapping a bridge should, if anything, pass the struct pci_dev of
> * that bridge. Since bridges don't normally get assigned to guests,
> * their owner would be the wrong one. Pass NULL instead.
> */
> -ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn,
> - NULL);
> +if ( ret >= 0 )
> +ret = domain_context_mapping_one(domain, drhd->iommu, bus,
> devfn,
> + NULL);
>
> /*
> * Devices behind PCIe-to-PCI/PCIx bridge may generate different
> @@ -1531,6 +1542,9 @@ static int domain_context_mapping(struct
> ret = domain_context_mapping_one(domain, drhd->iommu, secbus,
> 0,
> NULL);
>
> +if ( ret )
> +domain_context_unmap(domain, devfn, pdev);
> +
> break;
>
> default:
> @@ -1609,6 +1623,19 @@ int domain_context_unmap_one(
> if ( !iommu->drhd->segment && !rc )
> rc = me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC);
>
> +if ( rc && !is_hardware_domain(domain) && domain != dom_io )
> +{
> +if ( domain->is_dying )
> +{
> +printk(XENLOG_ERR "%pd: error %d
> unmapping %04x:%02x:%02x.%u\n",
> + domain, rc, iommu->drhd->segment, bus,
> + PCI_SLOT(devfn), PCI_FUNC(devfn));
> +rc = 0; /* Make upper layers continue in a best effort manner. */
> +}
> +else
> +domain_crash(domain);
> +}
> +
> return rc;
> }
>
> @@ -1661,17 +1688,29 @@ static int domain_context_unmap(struct d
>
> tmp_bus = bus;
> tmp_devfn = devfn;
> -if ( find_upstream_bridge(seg, &tmp_bus, &tmp_devfn, &secbus) < 1 )
> +if ( (ret = find_upstream_bridge(seg, &tmp_bus, &tmp_devfn,
> + &secbus)) < 1 )
> +{
> +if ( ret )
> +{
> +ret = -ENXIO;
> +if ( !domain->is_dying &&
> + !is_hardware_domain(domain) && domain != dom_io )
> +{
> +domain_crash(domain);
> +/* Make upper layers continue in a best effort manner. */
> +ret = 0;
> +}
> +}
> break;
> +}
>
> /* PCIe to PCI/PCIx bridge */
> if ( pdev_type(seg, tmp_bus, tmp_devfn) ==
> DEV_TYPE_PCIe2PCI_BRIDGE )
> {
> ret = domain_context_unmap_one(domain, iommu, tmp_bus,
> tmp_devfn);
> -if ( ret )
> -return ret;
> -
> -ret = domain_context_unmap_one(domain, iommu, secbus, 0);
> +if ( !ret )
> +ret = domain_context_unmap_one(domain, iommu, secbus, 0);
> }
> else /* Legacy PCI bridge */
> ret = domain_context_unmap_one(domain, iommu, tmp_bus,
> tmp_devfn);
RE: [PATCH 4/9] VT-d: adjust domid map updating when unmapping context
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:28 PM
>
> When an earlier error occurred, cleaning up the domid mapping data is
> wrong, as references likely still exist. The only exception to this is
> when the actual unmapping worked, but some flush failed (supposedly
> impossible after XSA-373). The guest will get crashed in such a case
> though, so add fallback cleanup to domain destruction to cover this
> case. This in turn makes it desirable to silence the dprintk() in
> domain_iommu_domid().
>
> Note that no error will be returned anymore when the lookup fails - in
> the common case lookup failure would already have caused
> domain_context_unmap_one() to fail, yet even from a more general
> perspective it doesn't look right to fail domain_context_unmap() in such
> a case when this was the last device, but not when any earlier unmap was
> otherwise successful.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -80,9 +80,11 @@ static int domain_iommu_domid(struct dom
> i = find_next_bit(iommu->domid_bitmap, nr_dom, i+1);
> }
>
> -dprintk(XENLOG_ERR VTDPREFIX,
> -"Cannot get valid iommu domid: domid=%d iommu->index=%d\n",
> -d->domain_id, iommu->index);
> +if ( !d->is_dying )
> +dprintk(XENLOG_ERR VTDPREFIX,
> +"Cannot get valid iommu %u domid: %pd\n",
> +iommu->index, d);
> +
> return -1;
> }
>
> @@ -147,6 +149,17 @@ static int context_get_domain_id(struct
> return domid;
> }
>
> +static void cleanup_domid_map(struct domain *domain, struct vtd_iommu
> *iommu)
> +{
> +int iommu_domid = domain_iommu_domid(domain, iommu);
> +
> +if ( iommu_domid >= 0 )
> +{
> +clear_bit(iommu_domid, iommu->domid_bitmap);
> +iommu->domid_map[iommu_domid] = 0;
> +}
> +}
> +
> static void sync_cache(const void *addr, unsigned int size)
> {
> static unsigned long clflush_size = 0;
> @@ -1724,6 +1737,9 @@ static int domain_context_unmap(struct d
> goto out;
> }
>
> +if ( ret )
> +goto out;
> +
> /*
> * if no other devices under the same iommu owned by this domain,
> * clear iommu in iommu_bitmap and clear domain_id in domid_bitmp
> @@ -1743,19 +1759,8 @@ static int domain_context_unmap(struct d
>
> if ( found == 0 )
> {
> -int iommu_domid;
> -
> clear_bit(iommu->index, &dom_iommu(domain)-
> >arch.vtd.iommu_bitmap);
> -
> -iommu_domid = domain_iommu_domid(domain, iommu);
> -if ( iommu_domid == -1 )
> -{
> -ret = -EINVAL;
> -goto out;
> -}
> -
> -clear_bit(iommu_domid, iommu->domid_bitmap);
> -iommu->domid_map[iommu_domid] = 0;
> +cleanup_domid_map(domain, iommu);
> }
>
> out:
> @@ -1775,6 +1780,7 @@ static void iommu_domain_teardown(struct
> {
> struct domain_iommu *hd = dom_iommu(d);
> struct mapped_rmrr *mrmrr, *tmp;
> +const struct acpi_drhd_unit *drhd;
>
> if ( list_empty(&acpi_drhd_units) )
> return;
> @@ -1786,6 +1792,9 @@ static void iommu_domain_teardown(struct
> }
>
> ASSERT(!hd->arch.vtd.pgd_maddr);
> +
> +for_each_drhd_unit ( drhd )
> +cleanup_domid_map(d, drhd->iommu);
> }
>
> static int __must_check intel_iommu_map_page(struct domain *d, dfn_t dfn,
RE: [PATCH 5/9] VT-d: clear_fault_bits() should clear all fault bits
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:29 PM
>
> If there is any way for one fault to be left set in the recording
> registers, there's no reason there couldn't also be multiple ones. If
> PPF set set (being the OR or all F fields), simply loop over the entire
> range of fault recording registers, clearing F everywhere.
>
> Since PPF is a r/o bit, also remove it from DMA_FSTS_FAULTS (arguably
> the constant's name is ambiguous as well).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2094,13 +2094,23 @@ static int __hwdom_init setup_hwdom_devi
>
> void clear_fault_bits(struct vtd_iommu *iommu)
> {
> -u64 val;
> unsigned long flags;
>
> spin_lock_irqsave(&iommu->register_lock, flags);
> -val = dmar_readq(iommu->reg, cap_fault_reg_offset(iommu->cap) + 8);
> -dmar_writeq(iommu->reg, cap_fault_reg_offset(iommu->cap) + 8, val);
> +
> +if ( dmar_readl(iommu->reg, DMAR_FSTS_REG) & DMA_FSTS_PPF )
> +{
> +unsigned int reg = cap_fault_reg_offset(iommu->cap);
> +unsigned int end = reg + cap_num_fault_regs(iommu->cap);
> +
> +do {
> + dmar_writel(iommu->reg, reg + 12, DMA_FRCD_F);
> + reg += PRIMARY_FAULT_REG_LEN;
> +} while ( reg < end );
> +}
> +
> dmar_writel(iommu->reg, DMAR_FSTS_REG, DMA_FSTS_FAULTS);
> +
> spin_unlock_irqrestore(&iommu->register_lock, flags);
> }
>
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -174,9 +174,8 @@
> #define DMA_FSTS_IQE (1u << 4)
> #define DMA_FSTS_ICE (1u << 5)
> #define DMA_FSTS_ITE (1u << 6)
> -#define DMA_FSTS_FAULTS (DMA_FSTS_PFO | DMA_FSTS_PPF |
> DMA_FSTS_AFO | \
> - DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | \
> - DMA_FSTS_ITE)
> +#define DMA_FSTS_FAULTS (DMA_FSTS_PFO | DMA_FSTS_AFO |
> DMA_FSTS_APF | \
> + DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE)
> #define dma_fsts_fault_record_index(s) (((s) >> 8) & 0xff)
>
> /* FRCD_REG, 32 bits access */
RE: [PATCH 6/9] VT-d: don't lose errors when flushing TLBs on multiple IOMMUs
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:29 PM
>
> While no longer an immediate problem with flushes no longer timing out,
> errors (if any) get properly reported by iommu_flush_iotlb_{dsi,psi}().
> Overwriting such an error with, perhaps, a success indicator received
> from another IOMMU will misguide callers. Record the first error, but
> don't bail from the loop (such that further necessary invalidation gets
> carried out on a best effort basis).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -643,7 +643,7 @@ static int __must_check iommu_flush_iotl
> struct vtd_iommu *iommu;
> bool_t flush_dev_iotlb;
> int iommu_domid;
> -int rc = 0;
> +int ret = 0;
>
> /*
> * No need pcideves_lock here because we have flush
> @@ -651,6 +651,8 @@ static int __must_check iommu_flush_iotl
> */
> for_each_drhd_unit ( drhd )
> {
> +int rc;
> +
> iommu = drhd->iommu;
>
> if ( !test_bit(iommu->index, &hd->arch.vtd.iommu_bitmap) )
> @@ -673,13 +675,12 @@ static int __must_check iommu_flush_iotl
> flush_dev_iotlb);
>
> if ( rc > 0 )
> -{
> iommu_flush_write_buffer(iommu);
> -rc = 0;
> -}
> +else if ( !ret )
> +ret = rc;
> }
>
> -return rc;
> +return ret;
> }
>
> static int __must_check iommu_flush_iotlb_pages(struct domain *d,
>
RE: [PATCH 7/9] VT-d: centralize mapping of QI entries
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:30 PM
>
> Introduce a helper function to reduce redundancy. Take the opportunity
> to express the logic without using the somewhat odd QINVAL_ENTRY_ORDER.
> Also take the opportunity to uniformly unmap after updating queue tail
> and dropping the lock (like was done so far only by
> queue_invalidate_context_sync()).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> ---
> I wonder though whether we wouldn't be better off permanently mapping
> the queue(s).
>
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -69,6 +69,16 @@ static void qinval_update_qtail(struct v
> dmar_writel(iommu->reg, DMAR_IQT_REG, val << QINVAL_INDEX_SHIFT);
> }
>
> +static struct qinval_entry *qi_map_entry(const struct vtd_iommu *iommu,
> + unsigned int index)
> +{
> +paddr_t base = iommu->qinval_maddr +
> + ((index * sizeof(struct qinval_entry)) & PAGE_MASK);
> +struct qinval_entry *entries = map_vtd_domain_page(base);
> +
> +return &entries[index % (PAGE_SIZE / sizeof(*entries))];
> +}
> +
> static int __must_check queue_invalidate_context_sync(struct vtd_iommu
> *iommu,
>u16 did, u16 source_id,
>u8 function_mask,
> @@ -76,15 +86,11 @@ static int __must_check queue_invalidate
> {
> unsigned long flags;
> unsigned int index;
> -u64 entry_base;
> -struct qinval_entry *qinval_entry, *qinval_entries;
> +struct qinval_entry *qinval_entry;
>
> spin_lock_irqsave(&iommu->register_lock, flags);
> index = qinval_next_index(iommu);
> -entry_base = iommu->qinval_maddr +
> - ((index >> QINVAL_ENTRY_ORDER) << PAGE_SHIFT);
> -qinval_entries = map_vtd_domain_page(entry_base);
> -qinval_entry = &qinval_entries[index % (1 << QINVAL_ENTRY_ORDER)];
> +qinval_entry = qi_map_entry(iommu, index);
>
> qinval_entry->q.cc_inv_dsc.lo.type = TYPE_INVAL_CONTEXT;
> qinval_entry->q.cc_inv_dsc.lo.granu = granu;
> @@ -98,7 +104,7 @@ static int __must_check queue_invalidate
> qinval_update_qtail(iommu, index);
> spin_unlock_irqrestore(&iommu->register_lock, flags);
>
> -unmap_vtd_domain_page(qinval_entries);
> +unmap_vtd_domain_page(qinval_entry);
>
> return invalidate_sync(iommu);
> }
> @@ -110,15 +116,11 @@ static int __must_check queue_invalidate
> {
> unsigned long flags;
> unsigned int index;
> -u64 entry_base;
> -struct qinval_entry *qinval_entry, *qinval_entries;
> +struct qinval_entry *qinval_entry;
>
> spin_lock_irqsave(&iommu->register_lock, flags);
> index = qinval_next_index(iommu);
> -entry_base = iommu->qinval_maddr +
> - ((index >> QINVAL_ENTRY_ORDER) << PAGE_SHIFT);
> -qinval_entries = map_vtd_domain_page(entry_base);
> -qinval_entry = &qinval_entries[index % (1 << QINVAL_ENTRY_ORDER)];
> +qinval_entry = qi_map_entry(iommu, index);
>
> qinval_entry->q.iotlb_inv_dsc.lo.type = TYPE_INVAL_IOTLB;
> qinval_entry->q.iotlb_inv_dsc.lo.granu = granu;
> @@ -133,10 +135,11 @@ static int __must_check queue_invalidate
> qinval_entry->q.iotlb_inv_dsc.hi.res_1 = 0;
> qinval_entry->q.iotlb_inv_dsc.hi.addr = addr >> PAGE_SHIFT_4K;
>
> -unmap_vtd_domain_page(qinval_entries);
> qinval_update_qtail(iommu, index);
> spin_unlock_irqrestore(&iommu->register_lock, flags);
>
> +unmap_vtd_domain_page(qinval_entry);
> +
> return invalidate_sync(iommu);
> }
>
> @@ -147,17 +150,13 @@ static int __must_check queue_invalidate
> static DEFINE_PER_CPU(uint32_t, poll_slot);
> unsigned int index;
> unsigned long flags;
> -u64 entry_base;
> -struct qinval_entry *qinval_entry, *qinval_entries;
> +struct qinval_entry *qinval_entry;
> uint32_t *this_poll_slot = &this_cpu(poll_slot);
>
> spin_lock_irqsave(&iommu->register_lock, flags);
> ACCESS_ONCE(*this_poll_slot) = QINVAL_STAT_INIT;
> index = qinval_next_index(iommu);
> -entry_base = iommu->qinval_maddr +
> - ((index >> QINVAL_ENTRY_ORDER) << PAGE_SHIFT);
> -qinval_entries = map_vtd_domain_page(entry_base);
> -qinval_entry = &qinval_entries[index % (1 << QINVAL_ENTRY_ORDER)];
> +qinval_entry = qi_map_entry(iommu, index);
>
> qinval_entry->q.inv_wait_dsc.lo.type = TYPE_INVAL_WAIT;
> qinval_entry->q.inv_wait_dsc.lo.iflag = iflag;
> @@ -167,10 +166,11 @@ static int __must_check queue_invalidate
> qinval_entry->q.inv_wait_dsc.lo.sdata = QINVAL_STAT_DONE;
> qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(this_poll_slot);
>
> -unmap_vtd_domain_page(qinval_entries);
> qinval_update_qtail(iommu, index);
> spin_unlock_irqrestore(&iommu->register_lock, flags);
>
> +unmap_vtd_domain_page(qinval_entry);
> +
>
RE: [PATCH 8/9] VT-d: drop/move a few QI related constants
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:30 PM
>
> Replace uses of QINVAL_ENTRY_ORDER and QINVAL_INDEX_SHIFT, such that
> the constants can be dropped. Move the remaining QINVAL_* ones to the
> single source file using them.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -451,17 +451,6 @@ struct qinval_entry {
> }q;
> };
>
> -/* Each entry is 16 bytes, so 2^8 entries per page */
> -#define QINVAL_ENTRY_ORDER ( PAGE_SHIFT - 4 )
> -#define QINVAL_MAX_ENTRY_NR (1u << (7 + QINVAL_ENTRY_ORDER))
> -
> -/* Status data flag */
> -#define QINVAL_STAT_INIT 0
> -#define QINVAL_STAT_DONE 1
> -
> -/* Queue invalidation head/tail shift */
> -#define QINVAL_INDEX_SHIFT 4
> -
> #define TYPE_INVAL_CONTEXT 0x1
> #define TYPE_INVAL_IOTLB0x2
> #define TYPE_INVAL_DEVICE_IOTLB 0x3
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -29,6 +29,13 @@
> #include "extern.h"
> #include "../ats.h"
>
> +/* Each entry is 16 bytes, and there can be up to 2^7 pages. */
> +#define QINVAL_MAX_ENTRY_NR (1u << (7 + PAGE_SHIFT_4K - 4))
> +
> +/* Status data flag */
> +#define QINVAL_STAT_INIT 0
> +#define QINVAL_STAT_DONE 1
> +
> static unsigned int __read_mostly qi_pg_order;
> static unsigned int __read_mostly qi_entry_nr;
>
> @@ -45,11 +52,11 @@ static unsigned int qinval_next_index(st
> {
> unsigned int tail = dmar_readl(iommu->reg, DMAR_IQT_REG);
>
> -tail >>= QINVAL_INDEX_SHIFT;
> +tail /= sizeof(struct qinval_entry);
>
> /* (tail+1 == head) indicates a full queue, wait for HW */
> while ( ((tail + 1) & (qi_entry_nr - 1)) ==
> -(dmar_readl(iommu->reg, DMAR_IQH_REG) >>
> QINVAL_INDEX_SHIFT) )
> +(dmar_readl(iommu->reg, DMAR_IQH_REG) / sizeof(struct
> qinval_entry)) )
> {
> printk_once(XENLOG_ERR VTDPREFIX " IOMMU#%u: no QI slot
> available\n",
> iommu->index);
> @@ -66,7 +73,7 @@ static void qinval_update_qtail(struct v
> /* Need hold register lock when update tail */
> ASSERT( spin_is_locked(&iommu->register_lock) );
> val = (index + 1) & (qi_entry_nr - 1);
> -dmar_writel(iommu->reg, DMAR_IQT_REG, val << QINVAL_INDEX_SHIFT);
> +dmar_writel(iommu->reg, DMAR_IQT_REG, val * sizeof(struct
> qinval_entry));
> }
>
> static struct qinval_entry *qi_map_entry(const struct vtd_iommu *iommu,
> @@ -413,17 +420,18 @@ int enable_qinval(struct vtd_iommu *iomm
> * only one entry left.
> */
> BUILD_BUG_ON(CONFIG_NR_CPUS * 2 >= QINVAL_MAX_ENTRY_NR);
> -qi_pg_order = get_order_from_bytes((num_present_cpus() * 2 + 1)
> <<
> - (PAGE_SHIFT -
> -QINVAL_ENTRY_ORDER));
> -qi_entry_nr = 1u << (qi_pg_order + QINVAL_ENTRY_ORDER);
> +qi_pg_order = get_order_from_bytes((num_present_cpus() * 2 + 1) *
> + sizeof(struct qinval_entry));
> +qi_entry_nr = (PAGE_SIZE << qi_pg_order) /
> + sizeof(struct qinval_entry);
>
> dprintk(XENLOG_INFO VTDPREFIX,
> "QI: using %u-entry ring(s)\n", qi_entry_nr);
> }
>
> iommu->qinval_maddr =
> -alloc_pgtable_maddr(qi_entry_nr >> QINVAL_ENTRY_ORDER,
> +alloc_pgtable_maddr(PFN_DOWN(qi_entry_nr *
> + sizeof(struct qinval_entry)),
> iommu->node);
> if ( iommu->qinval_maddr == 0 )
> {
Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
>
> is_swiotlb_force_bounce() was the new function introduced in this patch here.
>
> +static inline bool is_swiotlb_force_bounce(struct device *dev)
> +{
> + return dev->dma_io_tlb_mem->force_bounce;
> +}
To me the crash looks like dev->dma_io_tlb_mem is NULL. Can you
turn this into :
return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
for a quick debug check?
Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch
> > here.
> >
> > +static inline bool is_swiotlb_force_bounce(struct device *dev)
> > +{
> > + return dev->dma_io_tlb_mem->force_bounce;
> > +}
>
> To me the crash looks like dev->dma_io_tlb_mem is NULL. Can you
> turn this into :
>
> return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
>
> for a quick debug check?
I just realized that dma_io_tlb_mem might be NULL like Christoph
pointed out since swiotlb might not get initialized.
However, `Unable to handle kernel paging request at virtual address
dfff800e` looks more like the address is garbage rather than
NULL?
I wonder if that's because dev->dma_io_tlb_mem is not assigned
properly (which means device_initialize is not called?).
