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: Thu, 26 Mar 2020 18:05:16 +0100 From: Christoph Hellwig <hch@....de> To: Alexander Graf <graf@...zon.com> Cc: iommu@...ts.linux-foundation.org, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, x86@...nel.org, Christoph Hellwig <hch@....de>, Marek Szyprowski <m.szyprowski@...sung.com>, Robin Murphy <robin.murphy@....com>, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>, dwmw@...zon.com, benh@...zon.com, Jan Kiszka <jan.kiszka@...mens.com>, alcioa@...zon.com, aggh@...zon.com, aagch@...zon.com, dhr@...zon.com Subject: Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address On Thu, Mar 26, 2020 at 05:29:22PM +0100, Alexander Graf wrote: > The swiotlb is a very convenient fallback mechanism for bounce buffering of > DMAable data. It is usually used for the compatibility case where devices > can only DMA to a "low region". > > However, in some scenarios this "low region" may be bound even more > heavily. For example, there are embedded system where only an SRAM region > is shared between device and CPU. There are also heterogeneous computing > scenarios where only a subset of RAM is cache coherent between the > components of the system. There are partitioning hypervisors, where > a "control VM" that implements device emulation has limited view into a > partition's memory for DMA capabilities due to safety concerns. > > This patch adds a command line driven mechanism to move all DMA memory into > a predefined shared memory region which may or may not be part of the > physical address layout of the Operating System. > > Ideally, the typical path to set this configuration would be through Device > Tree or ACPI, but neither of the two mechanisms is standardized yet. Also, > in the x86 MicroVM use case, we have neither ACPI nor Device Tree, but > instead configure the system purely through kernel command line options. > > I'm sure other people will find the functionality useful going forward > though and extend it to be triggered by DT/ACPI in the future. I'm totally against hacking in a kernel parameter for this. We'll need a proper documented DT or ACPI way. We also need to feed this information into the actual DMA bounce buffering decisions and not just the swiotlb placement.
Powered by blists - more mailing lists