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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 19 Jun 2014 16:41:35 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Alex Williamson <alex.williamson@...hat.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	iommu@...ts.linux-foundation.org, chegu_vinod@...com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs
 from IOMMU API domains

On Thu, Jun 19, 2014 at 4:29 PM, Alex Williamson
<alex.williamson@...hat.com> wrote:
> But is there a way for software to discover its location from the
> device?  If so, then I think we can recreate all the identity maps we'd
> need for a guest from the device.  If not, then we'd need to figure out
> some IOMMU API extension to handle the mapping.  The spec excerpt above
> seems to indicate that hardware designers decided software doesn't need
> to know about it, but the RMRR seems to be the "oh crap" moment when
> they realized that yes we do need to know about it.  Thanks,

It's all specified somewhere how it exactly works. But we've just had
piles of fun trying to get the stolen range (i.e. for gfx buffer
usage, no the gtt pte block) to work correctly and it's not been fun.
The issue is that these registers are sw-defined and set by the bios.
And the bios team occasionally smokes strong stuff and nilly-willy
changes the definitions without telling anyone ... And we know that
there's more reserved stuff in that stolen range that occasionally
shouldn't be used by the driver. We have regular discussions with
them.

Otoh the same bios teams also set up the RMRR ranges with equallly
predictable results.

I don't have a recommendation here, but expect breakage no matter what you do.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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