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

Re: [Xen-devel] Buffers not reachable by PCI



Is it the translation that's in error?

Modeled after the translation in xen_swiotlb_dma_supported that's used for the 
problematic comparison, I added "the same" translation to swiotlb_print. I 
don't understand the results as dend - dstart is vastly larger that pend - 
pstart.



 void swiotlb_print_info(void)
 {
         unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
         phys_addr_t pstart, pend;
+        dma_addr_t dstart, dend;
 
+        pstart = virt_to_phys(io_tlb_start);
+        pend = virt_to_phys(io_tlb_end);
+
         dstart = phys_to_machine(XPADDR(pstart)).maddr;
         dend   = phys_to_machine(XPADDR(pend)). maddr;
 
         printk(KERN_INFO "Placing %luMB software IO TLB between %p - %p\n",
                bytes >> 20, io_tlb_start, io_tlb_end);
         printk(KERN_INFO "software IO TLB at phys %#llx - %#llx\n",
                (unsigned long long)pstart,
                 (unsigned long long)pend);
+        printk(KERN_INFO "software IO TLB at bus %#llx - %#llx\n",
+               (unsigned long long)dstart,
+                (unsigned long long)dend);
 }

Yields:
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00
[    0.000000] software IO TLB at bus 0x1c0f00 - 0x120fdff00

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.r.wilk@xxxxxxxxx] On Behalf Of 
Konrad Rzeszutek Wilk
Sent: Monday, December 12, 2011 4:19 PM
To: Taylor, Neal E
Cc: xen-devel; Kalev, Leonid; Dave, Tushar N
Subject: Re: [Xen-devel] Buffers not reachable by PCI

On Mon, Dec 12, 2011 at 10:11:20PM +0000, Taylor, Neal E wrote:
> We're having trouble getting a serial log. Are there other ways to capture 
> the information you need?
> 
> Attached is a dmesg with 'debug loglevel 8' set on the kernel line... 
> actually, with  
> 
>    #define DEFAULT_MESSAGE_LOGLEVEL 8
> 
> set near the top of printk.c as well, since I wasn't seeing any difference in 
> the log files with loglevel set to 8.

I needed this:

[    0.000000] Reserving virtual address space above 0xff800000
[    0.000000] Linux version 3.0.4-36.xen0 (root@nt-dev-Cent55-32) (gcc version 
4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Dec 12 14:54:39 EST 2011
[    0.000000] released 0 pages of unused memory
[    0.000000] 1-1 mapping on a0->100
[    0.000000] 1-1 mapping on bffc0->100000
[    0.000000] Set 262304 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000020000000 (usable)
[    0.000000]  Xen: 0000000020000000 - 00000000bffc0000 (unusable)
[    0.000000]  Xen: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
[    0.000000]  Xen: 00000000bffcfc00 - 00000000bffff000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000fec90000 (reserved)
[    0.000000]  Xen: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001dffc0000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.3 present.
[    0.000000] DMI: Dell Computer Corporation PowerEdge 1850/0RC130, BIOS A05 
01/09/2006
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) 
==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] last_pfn = 0x1dffc0 max_arch_pfn = 0x1000000
[    0.000000] found SMP MP-table at [c00fe710] fe710
[    0.000000] initial memory mapped : 0 - 023ff000
[    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
[    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
[    0.000000]  0000000000 - 00373fe000 page 4k
[    0.000000] kernel direct mapping tables up to 373fe000 @ 2242000-23ff000
[    0.000000] xen: setting RW the range 23ea000 - 23ff000
[    0.000000] RAMDISK: 016fb000 - 01ab2000
.. snip..
[    0.000000] Placing 64MB software IO TLB between d832cf00 - dc32cf00
[    0.000000] software IO TLB at phys 0x1832cf00 - 0x1c32cf00

And that tells me that 1) it is allocated above the 4GB - which
from a PFN perspectivie is not a big deal, as the MFNs are below 4GB
2), but it messes up the other drivers which expect the SWIOTLB to be
under 4GB.


Try this patch:

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8e964b9..600b53c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -166,7 +166,7 @@ retry:
        /*
         * Get IO TLB memory from any location.
         */
-       xen_io_tlb_start = alloc_bootmem(bytes);
+       xen_io_tlb_start = alloc_bootmem_low(bytes);
        if (!xen_io_tlb_start) {
                m = "Cannot allocate Xen-SWIOTLB buffer!\n";
                goto error;

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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