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

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



On Mon, Dec 12, 2011 at 03:16:24PM +0000, Jan Beulich wrote:
> >>> On 07.12.11 at 22:47, dbrace <dab@xxxxxx> wrote:
> > kernel: Linux 360 2.6.32.12-0.7-xen #1 SMP 2010-05-20 11:14:20 +0200 
> > i686 i686 i386 GNU/Linux
> 
> Pretty outdated.
> 
> > I am having issues with some code that uses kmap_atomic(). I am getting:
> > 
> > BUG: unable to handle kernel paging request at 23a1a000 (which is the 
> > address returned from kmap_atomic().)
> 
> For a valid high memory page this is surely not being returned by
> kmap_atomic(), so we have to assume that what you started with is
> the address of a low memory one.
> 
> > The same code works when running on non-XEN 32bit kernels so I am  
> > wondering why this does not work under
> > XEN kernels. Is there a different approach that I need to take for 32bit 
> > XEN kernels?
> 
> No, but ...
> 
> > I really only need to do this code segment if the memory address is a 
> > high memory address. Is there a MACRO or function
> > that can help me determine this?
> 
> PageHighMem().
> 
> > Here is a code snippet:
> > 
> >                  void *linux_vaddr = NULL;       /* kmapped temporary 
> > virtual address */
> >                  int linux_page_offset = 0;      /* offset in page */
> >                  int count = 0;                  /* bytes left to 
> > transfer */
> >                  int left = byte_count;          /* number of bytes left 
> > to transfer */
> >                  int memcpysize = 0;             /* current size to 
> > transfer */
> >                  struct page *linux_page = NULL; /* calculated page */
> >                  int kmap_flags = 0;
> > 
> >                  linux_page = __pfn_to_page(physical_address >> PAGE_SHIFT);
> 
> ... without knowing where you got physical_address from it's impossible
> to tell whether your problem is that under Xen physical and machine
> (sometimes called "bus") addresses being distinct (end hence you're
> possibly lacking a translation between the two).

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

_______________________________________________
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®.