All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@suse.de>
To: Muli Ben-Yehuda <mulix@mulix.org>
Cc: "Magenheimer,
	Dan (HP Labs Fort Collins)" <dan.magenheimer@hp.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	okrieg@us.ibm.com
Subject: Re: VP problematic for backend drivers on IA64?
Date: Wed, 25 Jan 2006 11:29:37 +0100	[thread overview]
Message-ID: <43D75311.3040808@suse.de> (raw)
In-Reply-To: <20060120015505.GB8504@granada.merseine.nu>

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.

cheers,

  Gerd

-- 
Gerd 'just married' Hoffmann <kraxel@suse.de>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg

  reply	other threads:[~2006-01-25 10:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20  1:55 VP problematic for backend drivers on IA64? Muli Ben-Yehuda
2006-01-25 10:29 ` Gerd Hoffmann [this message]
2006-01-25 14:37   ` Muli Ben-Yehuda
2006-01-25 16:24     ` Gerd Hoffmann
2006-01-25 16:46       ` Muli Ben-Yehuda
2006-01-25 16:56         ` Keir Fraser
2006-01-25 17:54           ` Muli Ben-Yehuda
  -- strict thread matches above, loose matches on Subject: below --
2006-01-20 17:08 Magenheimer, Dan (HP Labs Fort Collins)
2006-01-20 22:17 ` Muli Ben-Yehuda
2006-01-22 22:45 Magenheimer, Dan (HP Labs Fort Collins)
2006-01-24 23:42 Ian Pratt
2006-01-25  0:02 Magenheimer, Dan (HP Labs Fort Collins)
2006-01-25  0:16 ` Muli Ben-Yehuda
2006-01-25  1:35 Ian Pratt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D75311.3040808@suse.de \
    --to=kraxel@suse.de \
    --cc=dan.magenheimer@hp.com \
    --cc=mulix@mulix.org \
    --cc=okrieg@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.