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]
Date:	Thu, 26 Jan 2012 12:42:10 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Joerg Roedel <joerg.roedel@....com>
CC:	Sethi Varun-B16395 <B16395@...escale.com>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Tony Lindgren <tony@...mide.com>,
	Hiroshi DOYU <Hiroshi.DOYU@...ia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Wood Scott-B07421 <B07421@...escale.com>,
	David Brown <davidb@...eaurora.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 2/5] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

On 01/26/2012 12:31 PM, Joerg Roedel wrote:
> On Thu, Jan 26, 2012 at 12:25:32PM -0600, Scott Wood wrote:
>> How should a PAMU driver interpret "force_aperture"?  When would DMA
>> ever be allowed outside the specified range?  What does the range mean
>> in that case?
> 
> The force_aperture flag indicated whether DMA is only allowed between
> aperture_start and apertuer_end or if DMA is allowed outside of this
> range too (unmapped in this case).
> 
> The AMD GART for example would set this flag to false because it does
> not enforce DMA to be in the aperture-range.

Why is this not an AMD GART specific attribute?  Is there any feature
reporting mechanism by which a user would know if that flag is supported?

If it must be in the generic struct, it would be nice to invert the
polarity so that the default (after zeroing) is something that should be
more widely supportable, and less likely to create unintended identity
mappings.

How in general are available attributes and restrictions on possible
values to be communicated to users of the API?

-Scott

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ