Re: Buffers not reachable by PCI

[Konrad Rzeszutek Wilk <konrad@darnok.org>]

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;