This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] VP problematic for backend drivers on IA64?

To: Muli Ben-Yehuda <mulix@xxxxxxxxx>
Subject: Re: [Xen-devel] VP problematic for backend drivers on IA64?
From: Gerd Hoffmann <kraxel@xxxxxxx>
Date: Wed, 25 Jan 2006 11:29:37 +0100
Cc: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, okrieg@xxxxxxxxxx
Delivery-date: Wed, 25 Jan 2006 10:38:22 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060120015505.GB8504@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060120015505.GB8504@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20060111)
Muli Ben-Yehuda wrote:
> Hi Dan,
> I understand that during the IA64 session at the summit there was some
> discussion on VP being problematic for the current backend drivers (or
> the other way around), and IOMMUs were suggested as a possible
> solution. Could you please elaborate on what's the problem?

I'll try to give a short overview.  VP and IOMMU support are separate
problems, although there are some relations between the two ...

Current linux block device (also other) drivers use a "struct page", an
offset and the length to address some piece of memory, usually as source
or target for DMA.  Linux has an API (see Documentation/DMA-mapping.txt)
to translate a "struct page" to a DMA address for a specific device.
This was originally implemented to support IOMMUs.  It can also be used
to hide the phys=>machine address translation from device drivers, so
the current linux drivers run unmodified on VP.

The problem for the backend driver is that it submits I/O requests on
behalf of *other* domains.  Right now the backend driver maps the
foreign pages into it's own address space just to have a valid "struct
page" it can pass down to the block driver which talks to the real
hardware, although usually there is no need to do that to perform the
actual I/O.

One suggestion from the summit was to allocate some "struct page" for
foreign pages and tag them somehow (new page flag + grant table handle
in page->private maybe).  The xenified kernel's DMA mapping
implementation can check the flag then and do the "right thing".  I'm
not fully aware what other consequences this has for the linux memory
management, asking on lkml how to deal with that (and maybe get
other/better suggestions) is probably not a bad idea.  At least one
place which must also be touched for that is kmap()+friends.



Gerd 'just married' Hoffmann <kraxel@xxxxxxx>
I'm the hacker formerly known as Gerd Knorr.

Xen-devel mailing list