search for: config_has_dma

...uired_mask)(struct device *dev); + size_t (*max_mapping_size)(struct device *dev); }; #define DMA_MAPPING_ERROR (~(dma_addr_t)0) @@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev, } #endif +size_t dma_direct_max_mapping_size(struct device *dev); + #ifdef CONFIG_HAS_DMA #include <asm/dma-mapping.h> @@ -460,6 +463,7 @@ int dma_supported(struct device *dev, u64 mask); int dma_set_mask(struct device *dev, u64 mask); int dma_set_coherent_mask(struct device *dev, u64 mask); u64 dma_get_required_mask(struct device *dev); +size_t dma_max_mapping_size(struct d...

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,

...gt; patches. So we can poke at the archdata all day, but we can't build a > kernel like that :( I would like the s390 people to chime in here, it still looks like the best way to go if they can fix things on their side :-) > So until the dma_ops pointer move into struct device and > CONFIG_HAS_DMA becomes mandatory (or mandatory enough that virtio can > depend on it), I don't think we can do it this way. I see, it's a bummer because it would be a lot cleaner. > I'll send a v5 that is the same as v4 except with physical addressing > hardcoded in for powerpc. Thanks. Th...

...gt; patches. So we can poke at the archdata all day, but we can't build a > kernel like that :( I would like the s390 people to chime in here, it still looks like the best way to go if they can fix things on their side :-) > So until the dma_ops pointer move into struct device and > CONFIG_HAS_DMA becomes mandatory (or mandatory enough that virtio can > depend on it), I don't think we can do it this way. I see, it's a bummer because it would be a lot cleaner. > I'll send a v5 that is the same as v4 except with physical addressing > hardcoded in for powerpc. Thanks. Th...

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,

...<< VIRTIO_CONSOLE_F_MULTIPORT); } -static void free_buf(struct port_buffer *buf) +/* Allcoate data buffer from DMA memory if requested */ +static inline void * +alloc_databuf(struct virtio_device *vdev, size_t size, dma_addr_t *dma_handle, + gfp_t flag) { - kfree(buf->buf); +#ifdef CONFIG_HAS_DMA + if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_DMA_MEM)) { + struct device *dev = &vdev->dev; + /* + * Allocate DMA memory from ancestors. Finding the ancestor + * is a bit quirky when DMA_MEMORY_INCLUDES_CHILDREN is not + * implemented. + */ + dev = dev->parent ? dev->pare...

...<< VIRTIO_CONSOLE_F_MULTIPORT); } -static void free_buf(struct port_buffer *buf) +/* Allcoate data buffer from DMA memory if requested */ +static inline void * +alloc_databuf(struct virtio_device *vdev, size_t size, dma_addr_t *dma_handle, + gfp_t flag) { - kfree(buf->buf); +#ifdef CONFIG_HAS_DMA + if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_DMA_MEM)) { + struct device *dev = &vdev->dev; + /* + * Allocate DMA memory from ancestors. Finding the ancestor + * is a bit quirky when DMA_MEMORY_INCLUDES_CHILDREN is not + * implemented. + */ + dev = dev->parent ? dev->pare...

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,

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/

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,

On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote: > But there aren't any ACPI systems with both virtio-pci and IOMMUs, > right? So we could say that, henceforth, ACPI systems must declare > whether virtio-pci devices live behind IOMMUs without breaking > backward compatibility. I don't know for sure whether that's the case and whether we can rely on that not

On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote: > But there aren't any ACPI systems with both virtio-pci and IOMMUs, > right? So we could say that, henceforth, ACPI systems must declare > whether virtio-pci devices live behind IOMMUs without breaking > backward compatibility. I don't know for sure whether that's the case and whether we can rely on that not

...eturn &vq->vq; } diff --git a/tools/virtio/linux/dma-mapping.h b/tools/virtio/linux/dma-mapping.h new file mode 100644 index 000000000000..4f93af89ae16 --- /dev/null +++ b/tools/virtio/linux/dma-mapping.h @@ -0,0 +1,17 @@ +#ifndef _LINUX_DMA_MAPPING_H +#define _LINUX_DMA_MAPPING_H + +#ifdef CONFIG_HAS_DMA +# error Virtio userspace code does not support CONFIG_HAS_DMA +#endif + +#define PCI_DMA_BUS_IS_PHYS 1 + +enum dma_data_direction { + DMA_BIDIRECTIONAL = 0, + DMA_TO_DEVICE = 1, + DMA_FROM_DEVICE = 2, + DMA_NONE = 3, +}; + +#endif -- 2.5.0

...use the DMA API. Bigger quirk: on a standard s390 virtio guest configuration, dma_map_single etc will fail to link. I tried this in v1 of these patches. So we can poke at the archdata all day, but we can't build a kernel like that :( So until the dma_ops pointer move into struct device and CONFIG_HAS_DMA becomes mandatory (or mandatory enough that virtio can depend on it), I don't think we can do it this way. I'll send a v5 that is the same as v4 except with physical addressing hardcoded in for powerpc. --Andy

...t the archdata all day, but we can't build a >> kernel like that :( > > I would like the s390 people to chime in here, it still looks like the > best way to go if they can fix things on their side :-) > >> So until the dma_ops pointer move into struct device and >> CONFIG_HAS_DMA becomes mandatory (or mandatory enough that virtio can >> depend on it), I don't think we can do it this way. > > I see, it's a bummer because it would be a lot cleaner. > >> I'll send a v5 that is the same as v4 except with physical addressing >> hardcoded in...

...69c05f 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -35,8 +35,15 @@ #include <linux/wait.h> #include <linux/workqueue.h> #include <linux/module.h> +#include <linux/dma-mapping.h> #include "../tty/hvc/hvc_console.h" +#ifdef CONFIG_HAS_DMA +#define VIRTIO_CONSOLE_HAS_DMA (1) +#else +#define VIRTIO_CONSOLE_HAS_DMA (0) +#endif + /* * This is a global struct for storing common data for all the devices * this driver handles. @@ -334,20 +341,56 @@ static inline bool use_multiport(struct ports_device *portdev) return portdev->vde...