[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Retry 3: Use i386 swiotlb code in lib/swiotlb-xen.c [2/2]

>>> "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> 26.02.07 21:37 >>>
>Move the arch/i386/kernel/swiotlb.c code to lib/swiotlb-xen.c
>code in order to simplify maintenance of Xen in the future.
>The first patch simply moves the code to lib/swiotlb-xen.c;

Without the lib/Makefile adjustment the first patch can't work without
the second one.

>the second patch adds the necessary changes to the Xen code
>base to allow x86_64 systems to boot with SWIOTLB and the
>dma_ops framework.

>--- a/linux-2.6-xen-sparse/arch/x86_64/kernel/pci-dma-xen.c    Mon Feb 26 
>15:52:16 2007 -0600
>+++ b/linux-2.6-xen-sparse/arch/x86_64/kernel/pci-dma-xen.c    Mon Feb 26 
>15:58:43 2007 -0600
>+#include <xen/balloon.h>
>+#include <asm/tlbflush.h>

Why xen/balloon.h? asm/hypervisor.h is what declares

>+              /* Hardcode 31 address bits for now: aacraid limitation. */
>+              if (xen_create_contiguous_region((unsigned long)memory, 
>get_order(size), fls64(dma_mask)) != 0) {
>+                      free_pages((unsigned long)memory, get_order(size));
>+                      return NULL;
>+              }

Could we also get rid of the (now wrong) comment?

>--- a/linux-2.6-xen-sparse/lib/swiotlb-xen.c   Mon Feb 26 15:52:16 2007 -0600
>+++ b/linux-2.6-xen-sparse/lib/swiotlb-xen.c   Mon Feb 26 15:58:43 2007 -0600
>+swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
>+                      dma_addr_t dma_handle)
>+      if (in_swiotlb_aperture((dma_addr_t) vaddr))
>+              free_pages((unsigned long) vaddr, get_order(size));
>+      else
>+              /* DMA_TO_DEVICE to avoid memcpy in unmap_single */
>+              swiotlb_unmap_single (hwdev, dma_handle, size, DMA_TO_DEVICE);

I'm pretty certain this is wrong: dma_handle is what should be passed
to in_swiotlb_aperture().

>The first patch also copies the standard 
>arch/x86_64/kernel/pci-dma.c to arch/x86_64/kernel/pci-dma-xen.c,
>which should make reviewing the second patch a little easier.

While the second patch assumes the first patch does what you describe,
the first patch really just moves swiotlb.c.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.