On Thu, 23 Oct 2008 13:22:12 -0700
Keith Packard [EMAIL PROTECTED] wrote:
We just ran some numbers on a box with PAT enabled and broken MTRRs.
Finally we have a test platform for the difference between kmap_atomic
and kmap_atomic_prot. Using regular kmap_atomic on this platform, we get
UC
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote:
So I would suspect that if you guys actually write a patch, and make sure
that it works on x86-32 even _without_ CONFIG_HIGHMEM, and send it to
Ingo, good things will happen.
Something like the following (yes, I know, this is missing
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 23 Oct 2008, Keith Packard wrote:
So I'd much rather create a new linux/kmap.h or something. Or just
expose this from to asm/fixmap.h or something. Let's not confuse this
with highmem, even if the implementation _historically_ was
On Thu, 23 Oct 2008, Keith Packard wrote:
I'm fine with sticking the mapping in a separate structure; it's just
the return from ioremap_wc on 64-bit systems, and nothing at all on
32-bit systems.
Actually, on 32-bit, the 'prot' should be there, as should the starting
physical page.
On Fri, 2008-10-24 at 07:53 -0700, Linus Torvalds wrote:
Actually, on 32-bit, the 'prot' should be there, as should the starting
physical page. Otherwise the two interfaces would be very odd, and you'd
have to repeat those arguments in all callers (ie both in prepare and
in the actual
On Thu, 2008-10-23 at 13:38 -0700, Andrew Morton wrote:
I guess one could reimplemenet kmap_atomic_pfn() to call this. Sometime.
The goal is to stop needing this function fairly soon and replace it
with a 'real' io-mapping implementation for 32-bit processors.
Given that all
On Thu, 23 Oct 2008, Andrew Morton wrote:
Given that all highmem-implementing archtiectures must use the same
declaration here, we might as well put it into include/linux/highmem.h.
Although that goes against current mistakes^Wcode.
Does powerpc32 still implement highmem? It seems that
On Thu, 2008-10-23 at 14:24 -0700, Linus Torvalds wrote:
The whole point of that function has absolutely nothing to do with
highmem, and it *must* be useful on non-highmem configurations to be
appropriate.
Right, I'd just like my io_mapping_map_atomic_wc to be able to rapidly
map random
On Thu, 23 Oct 2008, Keith Packard wrote:
So I'd much rather create a new linux/kmap.h or something. Or just
expose this from to asm/fixmap.h or something. Let's not confuse this
with highmem, even if the implementation _historically_ was due to that.
Sure, we readily admit that
On Thu, 2008-10-23 at 14:24 -0700, Linus Torvalds wrote:
The whole point of that function has absolutely nothing to do with
highmem, and it *must* be useful on non-highmem configurations to be
appropriate.
So I'd much rather create a new linux/kmap.h or something. Or just
expose this
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote:
Then, there's the issue of 64-bit, and just mapping everything there, and
the interface to that. I liked the trivial extension to struct resource
to have a cached mapping pointer. So if we can just make it pass
resources around and
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote:
I'm not entirely sure who wants to own up to owning that particular part
of code, and is willing to make kmap_atomic_prot_pfn() also work in the
absense of CONFIG_HIGHMEM.
All of the kmap_atomic functions *do* work without
On Fri, 2008-10-24 at 14:24 +1100, Benjamin Herrenschmidt wrote:
I'm not that fan of carrying a mapping with a struct resource because if
we do that we should probably also refcount the mapping, and then there
is the whole question of mappings with different attributes, etc etc...
I'm fine
* Keith Packard [EMAIL PROTECTED] wrote:
On Mon, 2008-10-20 at 13:58 +0200, Ingo Molnar wrote:
yes but note that by caching the whole mapping on 64-bit we get
everything we want: trivially lockless, works from any CPU, can be
preempted at will, and there are no ugly INVLPG flushes
* Keith Packard [EMAIL PROTECTED] wrote:
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
the _real_ remapping in a graphics aperture happens on the GPU level
anyway, you manage an in-RAM GPU pagetable that just works like an
IOMMU, correct?
Yes, a one-level linear MMU which
* Ingo Molnar [EMAIL PROTECTED] wrote:
very nice!
I think we need a somewhat different abstraction though.
Firstly, regarding drivers/gpu/drm/i915/io_reserve.h, that needs to
move to generic code.
Secondly, wouldnt the right abstraction be to attach this
functionality to 'struct
* Keith Packard [EMAIL PROTECTED] wrote:
On Sun, 2008-10-19 at 19:53 +0200, Ingo Molnar wrote:
Note how simple and consistent it all gets: IO resources already
know their physical location and their size limits. Being able to
cache an ioremap in a mapping [and being able to use atomic
* Eric Anholt [EMAIL PROTECTED] wrote:
The APIs would be:
int io_resource_init_mapping(struct resource *res);
void io_resource_free_mapping(struct resource *res);
void * io_resource_map(struct resource *res, pfn_t pfn, unsigned long
offset);
void
* Ingo Molnar [EMAIL PROTECTED] wrote:
that gets ugly very fast. I think we should not use atomic kmaps but
NR_CPUS _fixmaps_ with a per CPU array of mutexes (this is basically
atomic kmaps but without the preemption restrictions). We could
take/drop the mutex and statistically you'll
On Sat, 18 Oct 2008, Eric Anholt wrote:
It's not being disloyal to your CEO, really. I'm pretty sure nobody will
be fired just for ignoring that whole 640kB^H^H^H^H^H32-bits should be
enough for everybody idiocy.
Writing 3D drivers means running 3D games. Running 3D games
On Friday, October 17, 2008 7:10 pm Eric Anholt wrote:
On Fri, 2008-10-17 at 15:43 -0700, Linus Torvalds wrote:
On Fri, 17 Oct 2008, Dave Airlie wrote:
So what's the excuse _this_ time for adding all these stupid warnings to
my build log? Did nobody test this?
On Mon, 2008-10-20 at 13:58 +0200, Ingo Molnar wrote:
yes but note that by caching the whole mapping on 64-bit we get
everything we want: trivially lockless, works from any CPU, can be
preempted at will, and there are no ugly INVLPG flushes anywhere.
I was assuming that on 64-bit, the map
On Sat, 2008-10-18 at 21:14 -0700, Keith Packard wrote:
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
Mind sending patches for this? :-)
Here's a patch for the i915 driver that includes the new API. Tested on
x86_32+HIGHMEM and x86_64. I stuck a new 'io_reserve.h' header in the
i915
On Sat, Oct 18, 2008 at 3:32 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
(In fact if we installed it into the linear kernel address space, and if
the aperture is 1GB aligned, we will automatically use gbpages for it.
Were Intel to support gbpages in the future ;-)
we could expand
On Sat, 18 Oct 2008 17:38:11 -0700
Keith Packard [EMAIL PROTECTED] wrote:
I've got Venki lined up to do this work for me; once we're happy
enough with the API. In particular, the non-highmem 32-bit case seems
a bit tricky.
Also, does anyone have a better set of names for this stuff?
On Sun, 19 Oct 2008 19:53:20 +0200
Ingo Molnar [EMAIL PROTECTED] wrote:
struct resource {
resource_size_t start;
resource_size_t end;
const char *name;
unsigned long flags;
struct resource *parent, *sibling, *child;
+ void *mapping;
};
* Keith Packard [EMAIL PROTECTED] wrote:
On Sat, 2008-10-18 at 21:14 -0700, Keith Packard wrote:
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
Mind sending patches for this? :-)
Here's a patch for the i915 driver that includes the new API. Tested
on x86_32+HIGHMEM and
On Sun, 2008-10-19 at 19:53 +0200, Ingo Molnar wrote:
* Keith Packard [EMAIL PROTECTED] wrote:
On Sat, 2008-10-18 at 21:14 -0700, Keith Packard wrote:
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
Mind sending patches for this? :-)
Here's a patch for the i915 driver
On Sat, 2008-10-18 at 00:49 -0700, Eric Anholt wrote:
Writing 3D drivers means running 3D games. Running 3D games
unfortunately means running a lot of 32-bit userland as the fun stuff is
binary-only. So I stick to a 32-bit system, becuase past experience
trying to run both on the same
On Sun, 2008-10-19 at 19:53 +0200, Ingo Molnar wrote:
Note how simple and consistent it all gets: IO resources already know
their physical location and their size limits. Being able to cache an
ioremap in a mapping [and being able to use atomic kmaps on 32-bit] is a
relatively simple and
On Sun, 2008-10-19 at 19:52 +0200, Peter Zijlstra wrote:
On Sat, 2008-10-18 at 00:49 -0700, Eric Anholt wrote:
Writing 3D drivers means running 3D games. Running 3D games
unfortunately means running a lot of 32-bit userland as the fun stuff is
binary-only. So I stick to a 32-bit system,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
On Fri, 2008-10-17 at 19:47 -0700, Linus Torvalds wrote:
Really? None of you use any modern CPU's, or you're _all_ running 32-bit
distros even though your cpu's could support 64-bit ones?
We're lazy, perhaps even lazier
On Fri, 2008-10-17 at 19:47 -0700, Linus Torvalds wrote:
On Fri, 17 Oct 2008, Eric Anholt wrote:
Yeah, none of us are on x86-64, so we missed those warnings in testing.
Really? None of you use any modern CPU's, or you're _all_ running 32-bit
distros even though your cpu's could
2008/10/18 Linus Torvalds [EMAIL PROTECTED]:
On Fri, 17 Oct 2008, Dave Airlie wrote:
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
Grr.
This whole merge series has been full of people sending me UNTESTED CRAP.
So
On Saturday 18 October 2008 08:29, Dave Airlie wrote:
Hi Linus,
This is a new tree, I had a conflict with your latest tree due to some
trivial cleanups you merged. I've added the fix for CVE-2008-3831 which is
unembargoed.
Please pull the 'drm-next' branch from
On Sat, 2008-10-18 at 12:37 +1100, Nick Piggin wrote:
OK. I was hoping that kmap_atomic_pfn thing *never* see the light of
mainline ;) Because hopefully the vmap improvements should be OK for
2.6.28 as well...
Eric and I chatted with Venki Pallipadi this week and decided what we
really need
On Sat, 18 Oct 2008, Keith Packard wrote:
The basic plan is to have four new functions (yes, I'm making up names
here):
struct io_mapping *io_reserve_pci_resource(struct pci_dev *dev,
int bar,
int
On Sat, 2008-10-18 at 12:31 -0700, Linus Torvalds wrote:
The important thing is that mappings need to be per-CPU, so the above may
work, but only if it's designed so that io_reserve_pci_resource() will
actually reserve space for 'nr_possible_cpu' page mappings, and then the
* Linus Torvalds [EMAIL PROTECTED] wrote:
[ The *non-atomic* kmap() functions are fairly high-overhead, in that they
want to keep track of cached mappings and remember page addresses etc.
So those are the ones we don't want to support for non-HIGHMEM setups.
But the atomic kmaps
* Keith Packard [EMAIL PROTECTED] wrote:
On Sat, 2008-10-18 at 22:37 +0200, Ingo Molnar wrote:
But i think the direction of the new GEM code is subtly wrong here,
because it tries to manage memory even on 64-bit systems. IMO it
should just map the _whole_ graphics aperture
On Sat, 18 Oct 2008, Jon Smirl wrote:
Is it possible to use a segment register to map the whole aperture on
32b?
No. Segment registers don't extend the virtual address space, they can
only limit visibility into the one single 32-bit one.
IOW, segment registers don't actually extend
On Sat, Oct 18, 2008 at 6:32 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Keith Packard [EMAIL PROTECTED] wrote:
On Sat, 2008-10-18 at 22:37 +0200, Ingo Molnar wrote:
But i think the direction of the new GEM code is subtly wrong here,
because it tries to manage memory even on 64-bit
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
the _real_ remapping in a graphics aperture happens on the GPU level
anyway, you manage an in-RAM GPU pagetable that just works like an
IOMMU, correct?
Yes, a one-level linear MMU which uses BIOS-reserved memory.
So, at least for a
On Sat, 2008-10-18 at 18:06 -0700, Arjan van de Ven wrote:
how about pci_resource_force_caching(pci_dev, barnr, cachetype)?
and then 'pci_map_atomic'? Not sure this makes sense in the pci
namespace.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
On Sunday 19 October 2008 06:31, Linus Torvalds wrote:
On Sat, 18 Oct 2008, Keith Packard wrote:
The basic plan is to have four new functions (yes, I'm making up names
here):
struct io_mapping *io_reserve_pci_resource(struct pci_dev *dev,
int
On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
Mind sending patches for this? :-)
Here's what these functions would look like as wrappers on top of the
existing APIs:
/* x86_64 style */
static inline struct io_reserve *
iomap_reserve(unsigned long base, unsigned long size)
{
Hi Linus,
This is a new tree, I had a conflict with your latest tree due to some
trivial cleanups you merged. I've added the fix for CVE-2008-3831 which is
unembargoed.
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
This
On Fri, 17 Oct 2008, Dave Airlie wrote:
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
Grr.
This whole merge series has been full of people sending me UNTESTED CRAP.
So what's the excuse _this_ time for adding all these
On Fri, 2008-10-17 at 15:43 -0700, Linus Torvalds wrote:
On Fri, 17 Oct 2008, Dave Airlie wrote:
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-next
Grr.
This whole merge series has been full of people sending me
On Fri, 17 Oct 2008, Eric Anholt wrote:
Yeah, none of us are on x86-64, so we missed those warnings in testing.
Really? None of you use any modern CPU's, or you're _all_ running 32-bit
distros even though your cpu's could support 64-bit ones?
I would suggest at least _somebody_ in the
On Fri, 2008-10-17 at 19:47 -0700, Linus Torvalds wrote:
Really? None of you use any modern CPU's, or you're _all_ running 32-bit
distros even though your cpu's could support 64-bit ones?
We're lazy, perhaps even lazier than yourself. Given that the whole goal
is to essentially ignore the CPU
51 matches
Mail list logo
