Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver code

["Brace, Don" <dab@xxxxxx>]

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?


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.

On non-XEN 32bit kernels I use kmap_atomic() and it handles both highmem 
addresses
and non highmem addresses with no issues.

When I am running 32bit XEN kernels I run into issues like this:
    "BUG: unable to handle kernel paging request at 9822bf40"

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
Sent: Thursday, December 15, 2011 2:44 AM
To: Konrad Rzeszutek Wilk
Cc: Brace, Don; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] kmap_atomic issue with SLES11SP1 32bit XEN driver code

>>> On 14.12.11 at 22:34, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> I don't know much about the SLES kernels, but if it uses lazy page
> updating it might be hitting:
> 
> 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be
> synchronous, regardless of lazy_mmu mode

We use lazy mode, but only in non-IRQ (and theoretically
preemption-enabled; theoretically because PREEMPT isn't a
permitted config option in the forward ported kernels) context.
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).

Jan


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