search for: dma_map_

...y > > long term and then maybe doing syncs on it as needed? > > In this case yes, pinned user memory, it gets sliced up into MTU sized > chunks, fed into an Rx queue of a device, and user can see packets > without any copies. How long is the life time of these mappings? Because dma_map_* assumes a temporary mapping and not one that is pinned bascically forever. > Quite similar use case #2 is upcoming io_uring / "direct placement" > patches (former from Meta, latter for Google) which will try to receive > just the TCP data into pinned user memory. I don't t...

...his has popped up in the past a few times already from people who want to use virtio as a transport between physical systems connected via a bus like PCI using non-transparent bridges for example. There's a way to get both here that isn't too nasty... we can make the virtio drivers use the dma_map_* APIs and just switch the dma_ops in the struct device based on the hypervisor requirements. IE. For KVM we could attach a set of ops that basically just return the physical address, real PCI transport would use the normal callbacks etc... The only problem at the moment is that the dma_map_ops, wh...

...his has popped up in the past a few times already from people who want to use virtio as a transport between physical systems connected via a bus like PCI using non-transparent bridges for example. There's a way to get both here that isn't too nasty... we can make the virtio drivers use the dma_map_* APIs and just switch the dma_ops in the struct device based on the hypervisor requirements. IE. For KVM we could attach a set of ops that basically just return the physical address, real PCI transport would use the normal callbacks etc... The only problem at the moment is that the dma_map_ops, wh...

...at DMA should be used instead. Ah, on 2nd look I've found it again. Quoting Documentation/DMA-API-HOWTO.txt: "Note that the DMA API works with any bus independent of the underlying microprocessor architecture. You should use the DMA API rather than the bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the pci_map_*() interfaces." The advice is fairly strong here I think ;-) And imo the idea makes sense, since it allows drivers like nouveau here to care much less about the actual bus used to get data to/from the ip block. And if you look at intel gfx it makes even...

...#39;t want to actually create IOMMU mappings for the KVM virio case. This would be a massive loss in performances on several platforms and generally doesn't make much sense. However, we can still use the API without that on any architecture where the dma mapping API ends up calling the generic dma_map_ops, it becomes just a matter of virtio setting up some special "nop" ops when needed. The difficulty here resides in the fact that we have never completely made the dma_map_ops generic. The ops themselves are defined generically as are the dma_map_* interfaces based on them, but the loca...

...okations with dma_map. As Daniel pointed out, using the PCI API is deprecated: Documentation/DMA-API-HOWTO.txt: "Note that the DMA API works with any bus independent of the underlying microprocessor architecture. You should use the DMA API rather than the bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the pci_map_*() interfaces." - As a result, removed the page mapping wrappers which have become unneeded. drm/nouveau_bo.c | 22 ++++++++++++++++------ lib/core/os.h | 8 ++++---- nvkm/engine/device/base.c | 25 ------------------------- n...

...hines communicate via a PCIe link (either with one as endpoint of the other or via a non-transparent switch). Which is why I'm not objecting to what you are trying to do ;-) My suggestion was that it might be a cleaner approach to do that by having the individual virtio drivers always use the dma_map_* API, and limiting the kludgery to a combination of virtio_pci "core" and arch code by selecting an appropriate set of dma_map_ops, defaulting with a "transparent" (or direct) one as our current default case (and thus overriding the iommu ones provided by the arch). > We c...

...the KVM virio case. This would be a massive > > loss in performances on several platforms and generally doesn't make > > much sense. > > > > However, we can still use the API without that on any architecture > > where the dma mapping API ends up calling the generic dma_map_ops, > > it becomes just a matter of virtio setting up some special "nop" ops > > when needed. > > I'm not quite convinced that this is a good idea. I think that there > are three relevant categories of virtio devices: > > a) Any virtio device where the no...

On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote: >> >> On x86, at least, I doubt that we'll ever see a physically addressed >> PCI virtio device for which ACPI advertises an IOMMU, since any sane >> hypervisor will just not advertise an IOMMU for the virtio

On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote: >> >> On x86, at least, I doubt that we'll ever see a physically addressed >> PCI virtio device for which ACPI advertises an IOMMU, since any sane >> hypervisor will just not advertise an IOMMU for the virtio

...reate IOMMU mappings for the KVM virio case. This would be a massive > loss in performances on several platforms and generally doesn't make > much sense. > > However, we can still use the API without that on any architecture > where the dma mapping API ends up calling the generic dma_map_ops, > it becomes just a matter of virtio setting up some special "nop" ops > when needed. I'm not quite convinced that this is a good idea. I think that there are three relevant categories of virtio devices: a) Any virtio device where the normal DMA ops are nops. This includ...

...reate IOMMU mappings for the KVM virio case. This would be a massive > loss in performances on several platforms and generally doesn't make > much sense. > > However, we can still use the API without that on any architecture > where the dma mapping API ends up calling the generic dma_map_ops, > it becomes just a matter of virtio setting up some special "nop" ops > when needed. I'm not quite convinced that this is a good idea. I think that there are three relevant categories of virtio devices: a) Any virtio device where the normal DMA ops are nops. This includ...

...el pointed > out, using the PCI API is deprecated: > Documentation/DMA-API-HOWTO.txt: > > "Note that the DMA API works with any bus independent of the underlying > microprocessor architecture. You should use the DMA API rather than the > bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the > pci_map_*() interfaces." > - As a result, removed the page mapping wrappers which have become > unneeded. Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> > > drm/nouveau_bo.c | 22 ++++++++++++++++------ > lib/core/os....

On Tue, Jul 08, 2014 at 05:25:59PM +0900, Alexandre Courbot wrote: > On architectures for which access to GPU memory is non-coherent, > caches need to be flushed and invalidated explicitly when BO control > changes between CPU and GPU. > > This patch adds buffer synchronization functions which invokes the > correct API (PCI or DMA) to ensure synchronization is effective. >

Currently, a lot of the virtio code assumes that bus (i.e. hypervisor) addresses are the same as physical address. This is false on Xen, so virtio is completely broken. I wouldn't be surprised if it also becomes a problem the first time that someone sticks a physical "virtio" device on a 32-bit bus on an ARM SOC with more than 4G RAM. Would you accept patches to convert

Currently, a lot of the virtio code assumes that bus (i.e. hypervisor) addresses are the same as physical address. This is false on Xen, so virtio is completely broken. I wouldn't be surprised if it also becomes a problem the first time that someone sticks a physical "virtio" device on a 32-bit bus on an ARM SOC with more than 4G RAM. Would you accept patches to convert

...nk it only needs to remain the default in cases where the alternative (bus addressing) won't work. I think that, so far, this is just ppc64. But see below... > > My suggestion was that it might be a cleaner approach to do that by > having the individual virtio drivers always use the dma_map_* API, and > limiting the kludgery to a combination of virtio_pci "core" and arch > code by selecting an appropriate set of dma_map_ops, defaulting with a > "transparent" (or direct) one as our current default case (and thus > overriding the iommu ones provided by the...

...nk it only needs to remain the default in cases where the alternative (bus addressing) won't work. I think that, so far, this is just ppc64. But see below... > > My suggestion was that it might be a cleaner approach to do that by > having the individual virtio drivers always use the dma_map_* API, and > limiting the kludgery to a combination of virtio_pci "core" and arch > code by selecting an appropriate set of dma_map_ops, defaulting with a > "transparent" (or direct) one as our current default case (and thus > overriding the iommu ones provided by the...

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,