user/sven/linux.git/drivers/virtio, branch v4.10.3

mm balloon: umount balloon_mnt when removing vb device

2017-03-12T05:44:10Z

commit 9c57b5808c625f4fc93da330b932647eaff321f7 upstream. With CONFIG_BALLOON_COMPACTION=y the kernel will mount balloon_mnt for balloon page migration when we probe a virtio_balloon device. However we do not unmount it when removing the device. Fix this. Fixes: b1123ea6d3b3 ("mm: balloon: use general non-lru movable page feature") Link: http://lkml.kernel.org/r/1486531318-35189-1-git-send-email-xieyisheng1@huawei.com Signed-off-by: Yisheng Xie Acked-by: Minchan Kim Cc: Rafael Aquini Cc: Konstantin Khlebnikov Cc: Gioh Kim Cc: Vlastimil Babka Cc: Michal Hocko Cc: Michael S. Tsirkin Cc: Jason Wang Cc: Hanjun Guo Cc: Xishi Qiu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Revert "vring: Force use of DMA API for ARM-based systems with legacy devices"

2017-02-03T21:38:50Z

This reverts commit c7070619f3408d9a0dffbed9149e6f00479cf43b. This has been shown to regress on some ARM systems: by forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate virtio-mmio devices in their guest DTs but neglect to add the often-overlooked "dma-coherent" property; as a result, we end up with the guest making non-cacheable accesses to the vring, the host doing so cacheably, both talking past each other and things going horribly wrong. We are working on a safer work-around. Fixes: c7070619f340 ("vring: Force use of DMA API for ARM-based systems with legacy devices") Reported-by: Robin Murphy Cc: Signed-off-by: Will Deacon Signed-off-by: Michael S. Tsirkin Acked-by: Marc Zyngier

vring: Force use of DMA API for ARM-based systems with legacy devices

2017-01-24T22:33:11Z

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 [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000 [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000 [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000 This is because the legacy virtio-blk device is behind an SMMU, so we have consequently swizzled its DMA ops and configured the SMMU to translate accesses. This then requires the vring code to use the DMA API to establish translations, otherwise all transactions will result in fatal faults and termination. Given that ARM-based systems only see an SMMU if one is really present (the topology is all described by firmware tables such as device-tree or IORT), then we can safely use the DMA API for all legacy virtio devices. Modern devices can advertise the prescense of an IOMMU using the VIRTIO_F_IOMMU_PLATFORM feature flag. Cc: Andy Lutomirski Cc: Michael S. Tsirkin Cc: Fixes: 876945dbf649 ("arm64: Hook up IOMMU dma_ops") Signed-off-by: Will Deacon Signed-off-by: Michael S. Tsirkin Acked-by: Marc Zyngier

virtio_mmio: Set DMA masks appropriately

2017-01-24T22:33:10Z

Once DMA API usage is enabled, it becomes apparent that virtio-mmio is inadvertently relying on the default 32-bit DMA mask, which leads to problems like rapidly exhausting SWIOTLB bounce buffers. Ensure that we set the appropriate 64-bit DMA mask whenever possible, with the coherent mask suitably limited for the legacy vring as per a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices"). Cc: Andy Lutomirski Cc: Michael S. Tsirkin Reported-by: Jean-Philippe Brucker Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled") Signed-off-by: Robin Murphy Signed-off-by: Michael S. Tsirkin

virtio_mmio: Set dev.release() to avoid warning

2016-12-15T22:13:39Z

Fix a warning thrown from virtio_mmio_remove(): Device 'virtio0' does not have a release() function The fix is according to virtio_pci_probe() of drivers/virtio/virtio_pci_common.c Signed-off-by: Yuan Liu Signed-off-by: Michael S. Tsirkin

virtio_ring: fix description of virtqueue_get_buf

2016-12-15T22:13:38Z

The device (not the driver) populates the used ring and includes the len of how much data was written. Signed-off-by: Felipe Franciosi Signed-off-by: Michael S. Tsirkin

virtio_pci: split vp_try_to_find_vqs into INTx and MSI-X variants

2016-12-15T22:12:49Z

There is basically no shared logic between the INTx and MSI-X case in vp_try_to_find_vqs, so split the function into two and clean them up a little bit. Also remove the fairly pointless vp_request_intx wrapper while we're at it. Signed-off-by: Christoph Hellwig Signed-off-by: Michael S. Tsirkin

virtio_pci: merge vp_free_vectors into vp_del_vqs

2016-12-15T22:12:48Z

Signed-off-by: Christoph Hellwig Signed-off-by: Michael S. Tsirkin

virtio_pci: remove the call to vp_free_vectors in vp_request_msix_vectors

2016-12-15T22:12:48Z

vp_request_msix_vectors is only called by vp_try_to_find_vqs, which already calls vp_free_vectors through vp_del_vqs in the failure case. Signed-off-by: Christoph Hellwig Signed-off-by: Michael S. Tsirkin

virtio_pci: use pci_alloc_irq_vectors

2016-12-15T22:12:47Z

This avoids the separate allocation for the msix_entries structures, and instead allows us to use pci_irq_vector to find a given IRQ vector. Signed-off-by: Christoph Hellwig Signed-off-by: Michael S. Tsirkin