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
| ||
|
Date: Tue, 18 Dec 2007 06:48:45 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Andi Kleen <ak@....de> Cc: Paul Mackerras <paulus@...ba.org>, Greg KH <gregkh@...e.de>, David Miller <davem@...emloft.net>, venkatesh.pallipadi@...el.com, rdreier@...co.com, torvalds@...ux-foundation.org, airlied@...net.ie, davej@...hat.com, mingo@...e.hu, tglx@...utronix.de, hpa@...or.com, akpm@...ux-foundation.org, arjan@...radead.org, jesse.barnes@...el.com, linux-kernel@...r.kernel.org, suresh.b.siddha@...el.com Subject: Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl Andi Kleen <ak@....de> writes: >> Well the other alternative looks like having a second file per par >> bar. Say resource0_wc to support the write-combining mode, possibly > > The intention was to support memory not in bars, but give a generic > IOMMU mapped memory interface for user space e.g. for the X server. > But that needs a way to return the bus address for the mmap mapping > and ioctl was the best I came up with for that. > Given it was never finished. Ok that part wasn't obvious. The only thing we mmap in sysfs today are the bars. Taking normal memory and iommu mapping it to a device and then having a user space accessible version is a bit different. We need a special interface to allocate it and map it through the iommu to user space. This needs to be a driver or a support subsystem like DRM. Once we have gone that far then we can map those address to user space. I expect from the sysfs perspective those per device regions should look a lot like bars showing contiguous chunks of memory RAM from the devices perspective. At which point having two files instead of just one can solve the problem without an ioctl. For contiguous to device memory we also have some permission issues so I'm not yet certain that it make sense to expose it through sysfs. Regardless that seems to be solving a completely new aspect of the problem, and we can solve that problem separately. Eric -- 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/
Powered by blists - more mailing lists