From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <ak@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jan Beulich <jbeulich@novell.com>,
Tony Luck <tony.luck@intel.com>,
Muli Ben-Yehuda <muli@il.ibm.com>
Subject: Re: dma_mapping_ops for i386
Date: Wed, 27 Jun 2007 14:40:21 -0400 [thread overview]
Message-ID: <4682AF15.5040906@goop.org> (raw)
In-Reply-To: <200706271726.51013.ak@suse.de>
Andi Kleen wrote:
> On Wednesday 27 June 2007 16:15:17 Jeremy Fitzhardinge wrote:
>
>> Andi Kleen wrote:
>>
>>> Ok, if you can do it without ifdefs.
>>>
>>>
>> That should be OK. All the existing i386 mapping operations would just
>> have their own ops structure, right?
>>
>
> I just mention it because many people's ideas of merging files
> seem to add lots of ifdefs which is imho the totally wrong thing
> to do.
>
>
>>> And no swiotlb on i386; that is something that is completely broken
>>> in upstream Xen and needs to be fixed properly anyways.
>>>
>>>
>> Hm, OK. I'm not really familiar with the issues here. What are they?
>> Looks like Jan has made a number of Xen-ish changes to lib/swiotlb.c;
>> are more changes be needed?
>>
>
> See the recent "quiet down swiotlb warnings" thread which uncovered
> quite some corpses in Xen's current IO setup.
>
> Xen apparently bounces for multi page IOs which get merged from block
> lists because the block layer doesn't know they are not really
> continuous in machine memory.
>
> Proper fix is to tell the block layer to not merge in the first
> place instead.
>
> And probably some similar mechanism for network drivers that limits
> MTUs.
>
Well, I think there are two issues here. One is that two
pseudo-physical pages won't necessarily be contigious in bus space,
because of the pseudo-phys to machine mapping.
The second problem is that devices which can't address all machine
physical memory (ie, 32-bit PCI devices on machines with >4G memory)
will need to have bouncebuffers established for them. Device drivers
won't necessarily be able to do it because they're not really aware of
machine addresses.
> Maybe we'll still need a simple bouncing mechanism for other obscure
> devices with large IOs then, but I would very much prefer if it wasn't
> swiotlb and could be solved some other way.
>
I think 32-bit-only devices are a bigger concern, no?
J
next prev parent reply other threads:[~2007-06-27 18:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-26 19:59 dma_mapping_ops for i386 Jeremy Fitzhardinge
2007-06-26 22:21 ` Andi Kleen
2007-06-27 14:15 ` Jeremy Fitzhardinge
2007-06-27 15:26 ` Andi Kleen
2007-06-27 18:40 ` Jeremy Fitzhardinge [this message]
2007-06-27 20:28 ` Muli Ben-Yehuda
2007-06-30 18:41 ` Herbert Xu
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=4682AF15.5040906@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=tony.luck@intel.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.