search for: __swiotlb_map_page

...gt;>> space for 491520 bytes >>> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be >>> DMA written >>> ... >>> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 >>> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 >>> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 >>> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 >>> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 >>> ... >>> [...

...gt;>> space for 491520 bytes >>> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be >>> DMA written >>> ... >>> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 >>> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 >>> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 >>> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 >>> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 >>> ... >>> [...

...aks on ARM > > using the default dma_ops? The breakage is not Xen related (except > > that Xen turns dma_ops on). The original message from Peng was: > > > > vring_map_one_sg -> vring_use_dma_api > > -> dma_map_page > > -> __swiotlb_map_page > > ->swiotlb_map_page > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address...

...aks on ARM > > using the default dma_ops? The breakage is not Xen related (except > > that Xen turns dma_ops on). The original message from Peng was: > > > > vring_map_one_sg -> vring_use_dma_api > > -> dma_map_page > > -> __swiotlb_map_page > > ->swiotlb_map_page > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address...

...io 1c130000.virtio_block: DMA: Out of SW-IOMMU > space for 491520 bytes > [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be > DMA written > ... > [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 > [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 > [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 > [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 > [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 > ... > [ 5.384449] [<ffff0000081829c4>]...

...io 1c130000.virtio_block: DMA: Out of SW-IOMMU > space for 491520 bytes > [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be > DMA written > ... > [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 > [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 > [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 > [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 > [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 > ... > [ 5.384449] [<ffff0000081829c4>]...

Booting Linux on an ARM fastmodel containing an SMMU emulation results in an unexpected I/O page fault from the legacy virtio-blk PCI device: [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002 [

Booting Linux on an ARM fastmodel containing an SMMU emulation results in an unexpected I/O page fault from the legacy virtio-blk PCI device: [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002 [

...s? If that is the case, how is it possible that virtio breaks on ARM using the default dma_ops? The breakage is not Xen related (except that Xen turns dma_ops on). The original message from Peng was: vring_map_one_sg -> vring_use_dma_api -> dma_map_page -> __swiotlb_map_page ->swiotlb_map_page ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must...

...s? If that is the case, how is it possible that virtio breaks on ARM using the default dma_ops? The breakage is not Xen related (except that Xen turns dma_ops on). The original message from Peng was: vring_map_one_sg -> vring_use_dma_api -> dma_map_page -> __swiotlb_map_page ->swiotlb_map_page ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must...

...g the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual add...

...520 bytes > >>> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be > >>> DMA written > >>> ... > >>> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 > >>> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 > >>> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 > >>> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 > >>> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 > >>&gt...

...: DMA: Out of SW-IOMMU >> space for 491520 bytes >> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be >> DMA written >> ... >> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 >> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 >> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 >> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 >> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 >> ... >> [ 5.384449] [<f...

...ytes) [ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU space for 491520 bytes [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be DMA written ... [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 ... [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/...

...520 bytes > >>> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be > >>> DMA written > >>> ... > >>> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0 > >>> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88 > >>> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88 > >>> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8 > >>> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 > >>&gt...

...s it possible that virtio breaks on ARM using > the default dma_ops? The breakage is not Xen related (except that Xen > turns dma_ops on). The original message from Peng was: > > vring_map_one_sg -> vring_use_dma_api > -> dma_map_page > -> __swiotlb_map_page > ->swiotlb_map_page > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); > However we are using per device dma area for rpmsg, phys_to_virt > could not return a correct virtual address for virtual address in > vmalloc area. T...

...g the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual add...

...e breakage is not Xen related (except > > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > > > vring_map_one_sg -> vring_use_dma_api > > > > -> dma_map_page > > > > -> __swiotlb_map_page > > > > ->swiotlb_map_page > > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > > dev_addr)), size, dir); > > > > However we are using per device dma area for rpmsg, phys_to_virt > > > > could not ret...

...e breakage is not Xen related (except > > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > > > vring_map_one_sg -> vring_use_dma_api > > > > -> dma_map_page > > > > -> __swiotlb_map_page > > > > ->swiotlb_map_page > > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > > dev_addr)), size, dir); > > > > However we are using per device dma area for rpmsg, phys_to_virt > > > > could not ret...

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > Use xen_swiotlb to determine when