From mboxrd@z Thu Jan 1 00:00:00 1970 From: dbrace Subject: Re: kmap_atomic issue with SLES11SP1 32bit XEN driver code Date: Thu, 15 Dec 2011 17:19:32 -0600 Message-ID: <4EEA8084.8030208@hp.com> References: <4EDFDF0D.2020104@hp.com> <4EE628D80200007800066F9E@nat28.tlf.novell.com> <20111214213443.GC25896@andromeda.dapyr.net> <4EE9C15602000078000680D3@nat28.tlf.novell.com> <6738613108553D49BEFEFDD59230CCDF011BED93@G4W3300.americas.hpqcorp.net> <4EEA304402000078000684C8@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EEA304402000078000684C8@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Can you give me some URLs to documentation that can help me understand my issue? Is sounds like I cannot go back to the correct virtual address after I map it for DMA. On 12/15/2011 10:37 AM, Jan Beulich wrote: >>>> On 15.12.11 at 17:15, "Brace, Don" wrote: >> I do not understand what this means: >> " That is, we'd be susceptible to this problem only if within a >> lazy-mode enabled section k{,un}map_atomic were used >> synchronously (which I'd consider a coding mistake)." >> >> Could you elaborate on this? > Not sure what additional explanation is needed. kmap_atomic() is > intended to be used in atomic context, and if you use it elsewhere > that's a mis-use. > >> Here is what I am trying to do. >> I am in a LLD I have bus addresses that are DMA-able that I would normally >> DMA to except this driver is emulating hardware in software and so it does >> not need to DMA is needs to transfer the data with the CPU. > So this makes clear that what I told you about a possibly missing > translation is likely the culprit. Quoting from your original mail > > linux_page = __pfn_to_page(physical_address>> PAGE_SHIFT); > > I have to assume that physical_address really isn't a physical address, > but a bus one. Hence you first need to translate it to a physical one > before passing it to __pfn_to_page(). > >> On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem >> addresses and non highmem addresses with no issues. > And so does it on Xen. > >> When I am running 32bit XEN kernels I run into issues like this: >> "BUG: unable to handle kernel paging request at 9822bf40" > Because you pass in a random struct page *. > > Jan > -- Don Brace SPSN Linux Development Hewlett-Packard Company