linux-kernel - Re: IO space memcpy support for userspace.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <119aab440812060807i8ca0583pdf9aa3b15bdc54fd@mail.gmail.com>
Date:	Sat, 6 Dec 2008 11:07:54 -0500
From:	"Carlos O'Donell" <carlos@...temhalted.org>
To:	"Dave Airlie" <airlied@...il.com>
Cc:	"David Miller" <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	libc-alpha@...rces.redhat.com
Subject: Re: IO space memcpy support for userspace.

On Sat, Dec 6, 2008 at 1:34 AM, Dave Airlie <airlied@...il.com> wrote:
> Its a real pain in the ass with dynamic buffer objects, we don't want userspace
> to care where they are located, the kernel migrates them in/out of
> video memory, GART, local RAM etc.
>
> However I suspect I just need on these platforms to ban any CPU
> accesses to pixmaps in VRAM. However
> sw fallbacks to the front buffer will always need these accesses.
>
> Its going to be a real pain getting any traction this stuff upstream
> (X.org/Mesa) where the world is x86 and maybe the odd powerpc, having
> to do special accessors for shithouse hw is never going to be fun.

Is there no case on x86 when this matters?

What about ARM, ColdFire or MIPS?

As the embedded market continues to grow I hope to see X.org/Mesa on
more hardware with different memory access rules.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/