search for: page_alignment

> +/* > + * Virtio direct mapping DMA API operations structure > + * > + * This defines DMA API structure for all virtio devices which would not > + * either bring in their own DMA OPS from architecture or they would not > + * like to use architecture specific IOMMU based DMA OPS because QEMU > + * expects GPA instead of an IOVA in absence of VIRTIO_F_IOMMU_PLATFORM. > + */

On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote: > On non-PPC systems, virtio_pci should use the DMA API. This fixes > virtio_pci on Xen. On PPC, using the DMA API would break things, so > we need to preserve the old behavior. > > The big comment in this patch explains the considerations in more > detail. I still disagree with using CONFIG_PPC as a trigger here.

On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote: > On non-PPC systems, virtio_pci should use the DMA API. This fixes > virtio_pci on Xen. On PPC, using the DMA API would break things, so > we need to preserve the old behavior. > > The big comment in this patch explains the considerations in more > detail. I still disagree with using CONFIG_PPC as a trigger here.

On Tue, Sep 16, 2014 at 10:22:27PM -0700, Andy Lutomirski wrote: > On non-PPC systems, virtio_pci should use the DMA API. This fixes > virtio_pci on Xen. On PPC, using the DMA API would break things, so > we need to preserve the old behavior. > > The big comment in this patch explains the considerations in more > detail. > > Signed-off-by: Andy Lutomirski <luto at

On Tue, Sep 16, 2014 at 10:22:27PM -0700, Andy Lutomirski wrote: > On non-PPC systems, virtio_pci should use the DMA API. This fixes > virtio_pci on Xen. On PPC, using the DMA API would break things, so > we need to preserve the old behavior. > > The big comment in this patch explains the considerations in more > detail. > > Signed-off-by: Andy Lutomirski <luto at

Normal boot path on system with iommu support: swiotlb buffer will be allocated early at first and then try to initialize iommu, if iommu for intel or AMD could setup properly, swiotlb buffer will be freed. The early allocating is with bootmem, and could panic when we try to use kdump with buffer above 4G only, or with memmap to limit mem under 4G. for example: memmap=4095M$1M to remove memory

Normal boot path on system with iommu support: swiotlb buffer will be allocated early at first and then try to initialize iommu, if iommu for intel or AMD could setup properly, swiotlb buffer will be freed. The early allocating is with bootmem, and could panic when we try to use kdump with buffer above 4G only, or with memmap to limit mem under 4G. for example: memmap=4095M$1M to remove memory

The PAGE_SIZE constant should be used instead of taking an extra parameter. Moreover, once we use PAGE_SIZE, we can use PAGE_ALIGN() instead of having it open coded. I've only compile tested the lguest launcher as I'm on a 64-bit system but I've tested the virtio-pci device with KVM. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> diff --git

The PAGE_SIZE constant should be used instead of taking an extra parameter. Moreover, once we use PAGE_SIZE, we can use PAGE_ALIGN() instead of having it open coded. I've only compile tested the lguest launcher as I'm on a 64-bit system but I've tested the virtio-pci device with KVM. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> diff --git

On non-PPC systems, virtio_pci should use the DMA API. This fixes virtio_pci on Xen. On PPC, using the DMA API would break things, so we need to preserve the old behavior. The big comment in this patch explains the considerations in more detail. Signed-off-by: Andy Lutomirski <luto at amacapital.net> --- drivers/virtio/virtio_pci.c | 90 ++++++++++++++++++++++++++++++++++++++++----- 1

On Wed, Sep 17, 2014 at 9:09 AM, Ira W. Snyder <iws at ovro.caltech.edu> wrote: > On Tue, Sep 16, 2014 at 10:22:27PM -0700, Andy Lutomirski wrote: >> On non-PPC systems, virtio_pci should use the DMA API. This fixes >> virtio_pci on Xen. On PPC, using the DMA API would break things, so >> we need to preserve the old behavior. >> >> The big comment in this

On Tue, Aug 26, 2014 at 02:17:02PM -0700, Andy Lutomirski wrote: > A virtqueue is a coherent DMA mapping. Use the DMA API for it. > This fixes virtio_pci on Xen. > > Signed-off-by: Andy Lutomirski <luto at amacapital.net> > --- > drivers/virtio/virtio_pci.c | 25 ++++++++++++++++++------- > 1 file changed, 18 insertions(+), 7 deletions(-) > > diff --git

On Tue, Aug 26, 2014 at 02:17:02PM -0700, Andy Lutomirski wrote: > A virtqueue is a coherent DMA mapping. Use the DMA API for it. > This fixes virtio_pci on Xen. > > Signed-off-by: Andy Lutomirski <luto at amacapital.net> > --- > drivers/virtio/virtio_pci.c | 25 ++++++++++++++++++------- > 1 file changed, 18 insertions(+), 7 deletions(-) > > diff --git

On Wed, Sep 17, 2014 at 08:02:31AM -0400, Benjamin Herrenschmidt wrote: > On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote: > > On non-PPC systems, virtio_pci should use the DMA API. This fixes > > virtio_pci on Xen. On PPC, using the DMA API would break things, so > > we need to preserve the old behavior. > > > > The big comment in this patch explains

Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. It applies on 2.6.22-rc2-mm2. Signed-off-by: Mathieu Desnoyers

Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. It applies on 2.6.22-rc2-mm2. Signed-off-by: Mathieu Desnoyers

Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. It applies on 2.6.22-rc2-mm2. Signed-off-by: Mathieu Desnoyers

...false; evict_mem.bus.io_reserved_count = 0; + evict_mem.bus.base = 0; + evict_mem.bus.offset = 0; + evict_mem.bus.addr = NULL; ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx); if (ret) { @@ -1084,6 +1087,9 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object *bo, mem.page_alignment = bo->mem.page_alignment; mem.bus.io_reserved_vm = false; mem.bus.io_reserved_count = 0; + mem.bus.base = 0; + mem.bus.offset = 0; + mem.bus.addr = NULL; mem.mm_node = NULL; /* @@ -1243,6 +1249,9 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev, bo->mem.page_alignment = page...

Current implementation of DMA API inside virtio core calls device's DMA OPS callback functions when the flag VIRTIO_F_IOMMU_PLATFORM flag is set. But in absence of the flag, virtio core falls back calling basic transformation of the incoming SG addresses as GPA. Going forward virtio should only call DMA API based transformations generating either GPA or IOVA depending on QEMU expectations

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,