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
|
Home