Re: [Xen-devel] blktap2 and CONFIG_XEN_BLKBACK_PAGEMAP

[Daniel Stodden <daniel.stodden@xxxxxxxxxx>]

On Thu, 2010-07-15 at 18:06 -0400, Shriram Rajagopalan wrote:
> 
> 
> On Thu, Jul 15, 2010 at 12:02 PM, Kaushik Kumar Ram <kaushik@xxxxxxxx>
> wrote:
>         
>         On Jul 15, 2010, at 1:19 PM, Shriram Rajagopalan wrote:
>         
>         > IIRC during my early experiments with blkback & blktap2, I
>         hit a similar error.. tracing through the code, I gathered
>         that the pagemap stuff is used to manage page grants to
>         blktap2 kernel driver . So, the #else (ie !BLKBK_PAGEMAP) code
>         is not going to work.
>         > I suggest, you try to look at the blkback_pagemap.c and the
>         blktap2/device.c or something like that to get a better
>         picture.
>         
>         
>         Thanks Shriram.0 I have been looking at the code over the past
>         few days. Since I am not familiar with the Linux block I/O
>         layers its taking a lot of time!
>         
>         It seems like on enabling CONFIG_BLKBACK_PAGEMAP the grant
>         mechanism is used to map guest pages into user space too. This
>         means the guest pages are mapped twice using the grant
>         mechanism, first into dom0 kernel space (in blkback/blback.c)
>         and then into tapdisk process's address space (in
>         blktap2/device.c).  This is the new implementation of blkback.
>         
> yep..
> 

Yes, it's pretty mandatory. It's needed to map foreign frames which have
been mapped by blkback back to their grants. I guess the Kconfigs should
reflect that. Didn't expect that it's just set to optional anywhere. 

The reason for the duplicate mapping is that userspace has to re-queue
those frames at the physical device layer, and -- iirc -- the problem
was that queuing pages twice, once on the blktap2 bdev and once on the
underlying disk, will deadlock.

So the second grant map basically creates an alias under a second pfn.
One page locally separate in two frames. Not exactly beautiful, but
effective.

>         On disabling CONFIG_BLKBACK_PAGEMAP, the code falls back on
>         the old implementation. Here, the guest pages are mapped into
>         user space by directly manipulating the page tables without
>         going through the grant mechanism. (Things seem slightly
>         different when XENFEAT_auto_translated_physmap is set but I
>         will ignore that for now). 
> IIRC, that XENFEAT_auto_translated_physmap is kinda deprecated..  it
> was used in xen 3.1 or so  I guess.. (basically, it makes pfn = mfn,
> instead of the current style : p2m & m2p tables)

Yes. That code has been there forever and then got carried over from
blktap1 to blktap2, basically as-is. Even to pvops, where it's probaby
broken. Empirical proof that nobody is using blktap2 with
autotranslation, at least not on recent kernels.

I guess it's going to stay there until autotranslation either gets more
en vogue again or evaporates altogether.

Cheers,
Daniel



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