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
| ||
|
Message-ID: <CAKMK7uE6Ab7pvyNvz7sd7QD1ZKDXd6kkEmXHxTzeFCmH1Z_bMQ@mail.gmail.com> Date: Thu, 19 Jun 2014 08:10:00 +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 3:47 AM, Alex Williamson <alex.williamson@...hat.com> wrote: > Finding some more specs... the MGGC0 register (50h) seems to indicate > the GTT stolen memory size is 2M, which sounds suspiciously like the 2M > that the RMRR is reporting. However, from the IvyBridge MMIO, Media > Registers & Programming Env manual: > > 4.6.1 Changes to GTT > > The GTT is constrained to be located at the beginning of a > special section of stolen memory called the GTT stolen memory > (GSM). There is no longer an MMIO register containing the > physical base address of the GTT as on prior devices. Instead of > using the PGTBL_CTL register to specify the base address of the > GTT, the GTT base is now defined to be at the bottom (offset 0) > of GSM. > > Since the graphics device (including the driver) knows nothing > about the location of GSM, it does not “know” where the GTT is > located in memory. In fact, the CPU cannot directly access the > GSM containing the GTT. > > That seems to suggest we can't discover this region from the device, but > the device does need to maintain access to it... I don't know how to > resolve that without exposing the RMRR through the IOMMU API. > > In any case, I don't know that any of this should block the original > patch. All of this seems like "acceptable" use of RMRRs that we can > later add an exception to allow if we get to the point of understanding > it and being able to reproduce any required mappings in the guest. > Thanks, GTT stolen is the place where the gpu stores page tables. We never access them directly but through a special mmio range so that the gpu can intercept pte updates and invalidate tlbs accordingly. So yeah, we need this, too. -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