search for: virtio_block

...>> >>> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size >>> based on read-ahead setting") unlocked read-ahead, we quickly run into >>> the limit of swiotlb and panic: >>> >>> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full >>> (sz: 491520 bytes) >>> [ 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 >>> ....

...>> >>> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size >>> based on read-ahead setting") unlocked read-ahead, we quickly run into >>> the limit of swiotlb and panic: >>> >>> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full >>> (sz: 491520 bytes) >>> [ 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 >>> ....

An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20080423/ea280a06/attachment.txt

An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20080423/ea280a06/attachment.txt

...which > limits the number of mappings. > > It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size > based on read-ahead setting") unlocked read-ahead, we quickly run into > the limit of swiotlb and panic: > > [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full > (sz: 491520 bytes) > [ 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>...

...which > limits the number of mappings. > > It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size > based on read-ahead setting") unlocked read-ahead, we quickly run into > the limit of swiotlb and panic: > > [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full > (sz: 491520 bytes) > [ 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>...

...; It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size > >>> based on read-ahead setting") unlocked read-ahead, we quickly run into > >>> the limit of swiotlb and panic: > >>> > >>> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full > >>> (sz: 491520 bytes) > >>> [ 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 > >>> D...

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 [

...number of mappings. >> >> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size >> based on read-ahead setting") unlocked read-ahead, we quickly run into >> the limit of swiotlb and panic: >> >> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full >> (sz: 491520 bytes) >> [ 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.38314...

...; It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size > >>> based on read-ahead setting") unlocked read-ahead, we quickly run into > >>> the limit of swiotlb and panic: > >>> > >>> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full > >>> (sz: 491520 bytes) > >>> [ 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 > >>> D...

...the DMA ops fall back to swiotlb, which limits the number of mappings. It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size based on read-ahead setting") unlocked read-ahead, we quickly run into the limit of swiotlb and panic: [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full (sz: 491520 bytes) [ 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 [...

...;IOMMU master node" of iommu.txt sufficient? Since the > iommus property applies to any DMA master, not only virtio-mmio devices, > the canonical description in iommu.txt seems the best place for it, and > I'm not sure what to add in this file. Maybe a short example below the > virtio_block one? No, because somewhere we have to capture if 'iommus' is valid for 'virtio-mmio' or not. Hopefully soon we'll actually be able to validate that. Rob

On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote: > A virtio-mmio node may represent a virtio-iommu device. This is discovered > by the virtio driver at probe time, but the DMA topology isn't > discoverable and must be described by firmware. For DT the standard IOMMU > description is used, as specified in bindings/iommu/iommu.txt and >

On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote: > A virtio-mmio node may represent a virtio-iommu device. This is discovered > by the virtio driver at probe time, but the DMA topology isn't > discoverable and must be described by firmware. For DT the standard IOMMU > description is used, as specified in bindings/iommu/iommu.txt and >

...u: + +- #iommu-cells: When the node describes a virtio-iommu device, it is + linked to DMA masters using the "iommus" property as + described in devicetree/bindings/iommu/iommu.txt. For + virtio-iommu #iommu-cells must be 1, each cell describing + a single endpoint ID. + Example: virtio_block at 3000 { -- 2.17.0

...'t section "IOMMU master node" of iommu.txt sufficient? Since the iommus property applies to any DMA master, not only virtio-mmio devices, the canonical description in iommu.txt seems the best place for it, and I'm not sure what to add in this file. Maybe a short example below the virtio_block one? Thanks, Jean

...evice accesses memory through an IOMMU, it should + have an "iommus" property [1]. Since virtio-iommu itself + does not access memory through an IOMMU, the "virtio,mmio" + node cannot have both an "#iommu-cells" and an "iommus" + property. + Example: virtio_block at 3000 { compatible = "virtio,mmio"; reg = <0x3000 0x100>; interrupts = <41>; + + /* Device has endpoint ID 23 */ + iommus = <&viommu 23> } + + viommu: virtio_iommu at 3100 { + compatible = "virtio,mmio"; + reg = <0x3100 0x100>; + int...

...ace Harvey Harrison (1): virtio: fix sparse return void-valued expression warnings Marcelo Tosatti (1): virtio-blk: fix remove oops Rusty Russell (11): virtio: ignore corrupted virtqueues rather than spinning. virtio: fix tx_ stats in virtio_net virtio: de-structify virtio_block status byte virtio: fix scatterlist sizing in net driver. virtio: wean net driver off NETDEV_TX_BUSY virtio: finer-grained features for virtio_net virtio: change config to guest endian. virtio: explicit advertisement of driver features lguest: avoid using NR_CPUS...

...ace Harvey Harrison (1): virtio: fix sparse return void-valued expression warnings Marcelo Tosatti (1): virtio-blk: fix remove oops Rusty Russell (11): virtio: ignore corrupted virtqueues rather than spinning. virtio: fix tx_ stats in virtio_net virtio: de-structify virtio_block status byte virtio: fix scatterlist sizing in net driver. virtio: wean net driver off NETDEV_TX_BUSY virtio: finer-grained features for virtio_net virtio: change config to guest endian. virtio: explicit advertisement of driver features lguest: avoid using NR_CPUS...