1. 16 6月, 2015 16 次提交
  2. 12 6月, 2015 1 次提交
    • D
      iommu/vt-d: Only enable extended context tables if PASID is supported · c83b2f20
      David Woodhouse 提交于
      Although the extended tables are theoretically a completely orthogonal
      feature to PASID and anything else that *uses* the newly-available bits,
      some of the early hardware has problems even when all we do is enable
      them and use only the same bits that were in the old context tables.
      
      For now, there's no motivation to support extended tables unless we're
      going to use PASID support to do SVM. So just don't use them unless
      PASID support is advertised too. Also add a command-line bailout just in
      case later chips also have issues.
      
      The equivalent problem for PASID support has already been fixed with the
      upcoming VT-d spec update and commit bd00c606 ("iommu/vt-d: Change
      PASID support to bit 40 of Extended Capability Register"), because the
      problematic platforms use the old definition of the PASID-capable bit,
      which is now marked as reserved and meaningless.
      
      So with this change, we'll magically start using ECS again only when we
      see the new hardware advertising "hey, we have PASID support and we
      actually tested it this time" on bit 40.
      
      The VT-d hardware architect has promised that we are not going to have
      any reason to support ECS *without* PASID any time soon, and he'll make
      sure he checks with us before changing that.
      
      In the future, if hypothetical new features also use new bits in the
      context tables and can be seen on implementations *without* PASID support,
      we might need to add their feature bits to the ecs_enabled() macro.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c83b2f20
  3. 02 6月, 2015 1 次提交
  4. 12 5月, 2015 1 次提交
    • W
      iommu/arm-smmu: Fix sign-extension of upstream bus addresses at stage 1 · 5dc5616e
      Will Deacon 提交于
      Stage 1 translation is controlled by two sets of page tables (TTBR0 and
      TTBR1) which grow up and down from zero respectively in the ARMv8
      translation regime. For the SMMU, we only care about TTBR0 and, in the
      case of a 48-bit virtual space, we expect to map virtual addresses 0x0
      through to 0xffff_ffff_ffff.
      
      Given that some masters may be incapable of emitting virtual addresses
      targetting TTBR1 (e.g. because they sit on a 48-bit bus), the SMMU
      architecture allows bit 47 to be sign-extended, halving the virtual
      range of TTBR0 but allowing TTBR1 to be used. This is controlled by the
      SEP field in TTBCR2.
      
      The SMMU driver incorrectly enables this sign-extension feature, which
      causes problems when userspace addresses are programmed into a master
      device with the SMMU expecting to map the incoming transactions via
      TTBR0; if the top bit of address is set, we will instead get a
      translation fault since TTBR1 walks are disabled in the TTBCR.
      
      This patch fixes the issue by disabling sign-extension of a fixed
      virtual address bit and instead basing the behaviour on the upstream bus
      size: the incoming address is zero extended unless the upstream bus is
      only 49 bits wide, in which case bit 48 is used as the sign bit and is
      replicated to the upper bits.
      
      Cc: <stable@vger.kernel.org> # v4.0+
      Reported-by: NVarun Sethi <varun.sethi@freescale.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5dc5616e
  5. 11 5月, 2015 1 次提交
    • D
      iommu/vt-d: Fix passthrough mode with translation-disabled devices · 4ed6a540
      David Woodhouse 提交于
      When we use 'intel_iommu=igfx_off' to disable translation for the
      graphics, and when we discover that the BIOS has misconfigured the DMAR
      setup for I/OAT, we use a special DUMMY_DEVICE_DOMAIN_INFO value in
      dev->archdata.iommu to indicate that translation is disabled.
      
      With passthrough mode, we were attempting to dereference that as a
      normal pointer to a struct device_domain_info when setting up an
      identity mapping for the affected device.
      
      This fixes the problem by making device_to_iommu() explicitly check for
      the special value and indicate that no IOMMU was found to handle the
      devices in question.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Cc: stable@vger.kernel.org (which means you can pick up 18436afd now too)
      4ed6a540
  6. 05 5月, 2015 1 次提交
  7. 04 5月, 2015 1 次提交
  8. 02 4月, 2015 9 次提交
  9. 31 3月, 2015 9 次提交