search for: page_aligned

> +/* > + * 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

...ng.orig/arch/i386/xen/xen-head.S 2007-08-19 22:45:58.000000000 -0400 +++ linux-2.6-lttng/arch/i386/xen/xen-head.S 2007-08-19 22:46:19.000000000 -0400 @@ -13,6 +13,7 @@ ENTRY(startup_xen) cld movl $(init_thread_union+THREAD_SIZE),%esp jmp xen_start_kernel + .previous .pushsection ".bss.page_aligned" .align PAGE_SIZE_asm @@ -34,5 +35,6 @@ ENTRY(hypercall_page) ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "no") #endif ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic") + .previous #endif /*CONFIG_XEN */ -- Mathieu Desnoyers Computer Engineering Ph....

...ng.orig/arch/i386/xen/xen-head.S 2007-08-19 22:45:58.000000000 -0400 +++ linux-2.6-lttng/arch/i386/xen/xen-head.S 2007-08-19 22:46:19.000000000 -0400 @@ -13,6 +13,7 @@ ENTRY(startup_xen) cld movl $(init_thread_union+THREAD_SIZE),%esp jmp xen_start_kernel + .previous .pushsection ".bss.page_aligned" .align PAGE_SIZE_asm @@ -34,5 +35,6 @@ ENTRY(hypercall_page) ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "no") #endif ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic") + .previous #endif /*CONFIG_XEN */ -- Mathieu Desnoyers Computer Engineering Ph....

...ng.orig/arch/i386/xen/xen-head.S 2007-08-19 22:45:58.000000000 -0400 +++ linux-2.6-lttng/arch/i386/xen/xen-head.S 2007-08-19 22:46:19.000000000 -0400 @@ -13,6 +13,7 @@ ENTRY(startup_xen) cld movl $(init_thread_union+THREAD_SIZE),%esp jmp xen_start_kernel + .previous .pushsection ".bss.page_aligned" .align PAGE_SIZE_asm @@ -34,5 +35,6 @@ ENTRY(hypercall_page) ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "no") #endif ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic") + .previous #endif /*CONFIG_XEN */ -- Mathieu Desnoyers Computer Engineering Ph....

We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index e3931e515906..772c640a6046 100644 ---

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,