similar to: [Bug 23830] New: nouvea modules on 2.6.31-rc6 failed

On 09/02/09 01:10, Mitchell E Berger wrote: > I apologize for writing to you directly instead of through an officially > supported channel. No problem. > I''ve filed a bug against glibc in Redhat''s Bugzilla > for an issue that only seems to surface on 64-bit Xen paravirt guests > on AMD hosts. Filing this bug with the distro involved seemed to make > sense,

This API is the equivalent of alloc_pages, except that the returned memory is guaranteed to be DMA addressable by the passed in device. The implementation will also be used to provide a more sensible replacement for DMA_ATTR_NON_CONSISTENT flag. Additionally dma_alloc_noncoherent is switched over to use dma_alloc_pages as its backend. Signed-off-by: Christoph Hellwig <hch at lst.de> ---

Add a new API to allocate and free pages that are guaranteed to be addressable by a device, but otherwise behave like pages allocated by alloc_pages. The intended APIs to sync them for use with the device and cpu are dma_sync_single_for_{device,cpu} that are also used for streaming mappings. Switch all drivers over to this new API, but keep the usage of the crufty dma_cache_sync API for now,

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- drivers/xen/swiotlb-xen.c | 14 +++++++------- include/xen/swiotlb-xen.h | 12 ++++++------ 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 104f89a60ef5ec77d6f559eac4676844b3480740 commit: 155fcd8511de5f99c27a726e9153b87cce528b6e [3/23] swiotlb: Add is_swiotlb_active() function config: i386-tinyconfig (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: git checkout 155fcd8511de5f99c27a726e9153b87cce528b6e #

On Tue, Apr 28, 2020 at 05:09:18PM +0530, Srivatsa Vaddagiri wrote: > For better security, its desirable that a guest VM's memory is > not accessible to any entity that executes outside the context of > guest VM. In case of virtio, backend drivers execute outside the > context of guest VM and in general will need access to complete > guest VM memory. One option to restrict the

On arm64 the dma_map_ops implementation is based on the swiotlb. swiotlb-xen, used by default in dom0 on Xen, is also based on the swiotlb. Avoid calling into the default arm64 dma_map_ops functions from xen_dma_map_page, xen_dma_unmap_page, xen_dma_sync_single_for_cpu, and xen_dma_sync_single_for_device otherwise we end up calling into the swiotlb twice. When arm64 gets a non-swiotlb based

Hi, The fifth version of this patchset was merged by Andrew Morton few days ago. It was rebased on v4.7-rc5 so it missed some ongoing changes. This is just rebase on next-20160713. For easier testing the patchset is available here: repo: https://github.com/krzk/linux branch: for-next/dma-attrs-const-v6 Changes since v5 ================ 1. New patches: 1/46: [media] mtk-vcodec: Remove

Allow the dma-iommu api to use bounce buffers for untrusted devices. This is a copy of the intel bounce buffer code. Signed-off-by: Tom Murphy <murphyt7 at tcd.ie> --- drivers/iommu/dma-iommu.c | 93 ++++++++++++++++++++++++++++++++------- drivers/iommu/iommu.c | 10 +++++ include/linux/iommu.h | 9 +++- 3 files changed, 95 insertions(+), 17 deletions(-) diff --git

We should only assign intel_dma_ops to devices which will actually use the iommu and let the default fall back dma_direct_* functions handle all other devices. This won't change any behaviour but will just use the generic implementations for direct mapped devices rather than intel specific ones. Signed-off-by: Tom Murphy <murphyt7 at tcd.ie> --- drivers/iommu/intel-iommu.c | 52

From: Joerg Roedel <jroedel at suse.de> The function returns the maximum size that can be mapped using DMA-API functions. The patch also adds the implementation for direct DMA and a new dma_map_ops pointer so that other implementations can expose their limit. Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> Reviewed-by: Christoph Hellwig <hch at lst.de>

On Tue, Feb 02, 2016 at 09:46:36PM -0800, Andy Lutomirski wrote: > virtio_ring currently sends the device (usually a hypervisor) > physical addresses of its I/O buffers. This is okay when DMA > addresses and physical addresses are the same thing, but this isn't > always the case. For example, this never works on Xen guests, and > it is likely to fail if a physical

On Tue, Feb 02, 2016 at 09:46:36PM -0800, Andy Lutomirski wrote: > virtio_ring currently sends the device (usually a hypervisor) > physical addresses of its I/O buffers. This is okay when DMA > addresses and physical addresses are the same thing, but this isn't > always the case. For example, this never works on Xen guests, and > it is likely to fail if a physical

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 104f89a60ef5ec77d6f559eac4676844b3480740 commit: 951a381d4c0d45a9b44de30228c6ef17083854ea [2/23] swiotlb: Introduce swiotlb_max_mapping_size() config: i386-tinyconfig (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: git checkout 951a381d4c0d45a9b44de30228c6ef17083854ea #

virtio_ring currently sends the device (usually a hypervisor) physical addresses of its I/O buffers. This is okay when DMA addresses and physical addresses are the same thing, but this isn't always the case. For example, this never works on Xen guests, and it is likely to fail if a physical "virtio" device ever ends up behind an IOMMU or swiotlb. The immediate use case for me is

Hi, here is the next version of this patch-set. Previous versions can be found here: V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ V3: https://lore.kernel.org/lkml/20190123163049.24863-1-joro at 8bytes.org/ V4: https://lore.kernel.org/lkml/20190129084342.26030-1-joro at 8bytes.org/

virtio_ring currently sends the device (usually a hypervisor) physical addresses of its I/O buffers. This is okay when DMA addresses and physical addresses are the same thing, but this isn't always the case. For example, this never works on Xen guests, and it is likely to fail if a physical "virtio" device ever ends up behind an IOMMU or swiotlb. The immediate use case for me is

All users are gone now, remove the API. Signed-off-by: Christoph Hellwig <hch at lst.de> --- arch/mips/Kconfig | 1 - arch/mips/jazz/jazzdma.c | 1 - arch/mips/mm/dma-noncoherent.c | 6 ------ arch/parisc/Kconfig | 1 - arch/parisc/kernel/pci-dma.c | 6 ------ include/linux/dma-mapping.h | 8 -------- include/linux/dma-noncoherent.h | 10

It seems the problems running mthca in a Xen domU have uncovered a bug in mthca: mthca uses dma_sync_single in mthca_arbel_write_mtt_seg() and mthca_arbel_map_phys_fmr() to sync the MTTs that get written. However, Documentation/DMA-API.txt says: void dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) synchronise a single

On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote: > Hi, > > > This is fifth approach for replacing struct dma_attrs with unsigned > long. > > The main patch (1/44) doing the change is split into many subpatches > for easier review (2-42). They should be squashed together when > applying. For all the drm driver patches: Acked-by: Daniel Vetter