All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir@xensource.com>
To: Jan Beulich <jbeulich@novell.com>, Keir Fraser <keir@xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: x86 swiotlb questions
Date: Mon, 18 Dec 2006 09:39:07 +0000	[thread overview]
Message-ID: <C1AC123B.5FFA%keir@xensource.com> (raw)
In-Reply-To: <45865508.76E4.0078.0@novell.com>

On 18/12/06 7:44 am, "Jan Beulich" <jbeulich@novell.com> wrote:

>> Same here. We didn't implement this. It doesn't seem to make that much
>> sense. Sync'ing with lib/swiotb.c and throwing away our special one would be
>> very nice. :-)
> 
> Trying to do that I find one extra issue: in_swiotlb_aperture() does its check
> based on pfn, while lib/swiotlb.c uses the virtual address in the respective
> checks instead. Is there some subtlety behind that (that then should be
> commented upon), or is this just due to this originally having been an
> mfn-based check?

Yes, it's because we used to do an mfn range check which was okay when the
swiotlb aperture was filled with contiguous machine memory. Since it is
composed of discontiguous slabs now, we changed to a pfn check but that
could equally well be a virtual-address check.

Do we merge okay with lib/swiotlb.c then? One concern I had was with our
preferred setup semantics -- we really want the user to be able to forcibly
enable the swiotlb via a boot parameter *but* not have to suffer using it
for every DMA operation. Last I looked the generic swiotlb didn't have that
option. That and our very Xen-specific checks for whether to auto-enable the
swiotlb led me to think that the very start-of-day setup of swiotlb would
need to be overridable by architecture.

 -- Keir

  reply	other threads:[~2006-12-18  9:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-15 12:50 x86 swiotlb questions Jan Beulich
2006-12-15 13:35 ` Keir Fraser
2006-12-15 13:53   ` Jan Beulich
2006-12-15 14:03     ` Keir Fraser
2006-12-15 14:17       ` Jan Beulich
2006-12-15 14:19         ` Keir Fraser
2006-12-15 14:46           ` Jan Beulich
2006-12-15 16:47             ` Keir Fraser
2006-12-15 16:19   ` Alan
2006-12-18  7:44   ` Jan Beulich
2006-12-18  9:39     ` Keir Fraser [this message]
2006-12-19 12:48       ` Jan Beulich
2006-12-19 14:14         ` Keir Fraser
2006-12-19 14:39           ` Jan Beulich
2006-12-19 14:46             ` Keir Fraser
2006-12-19 17:07               ` Muli Ben-Yehuda
2006-12-20 16:40       ` Jan Beulich
  -- strict thread matches above, loose matches on Subject: below --
2006-12-22 14:49 Jan Beulich
2006-12-25  4:50 ` Muli Ben-Yehuda
2006-12-25 10:20   ` Keir Fraser
2006-12-22 16:20 Jan Beulich
2006-12-22 21:00 ` Herbert Xu
2006-12-23  9:48 ` Keir Fraser
2006-12-30 17:32 Jan Beulich
2006-12-30 17:47 ` Keir Fraser
2007-01-02  8:39   ` Jan Beulich
2007-01-03  7:10   ` Jan Beulich
2007-01-03  9:32     ` Keir Fraser
2007-01-03 11:01       ` Jan Beulich

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=C1AC123B.5FFA%keir@xensource.com \
    --to=keir@xensource.com \
    --cc=jbeulich@novell.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.