)]}'
{
  "commit": "1ef3e2bc04223ff956dc62abaf2dff1f3322a431",
  "tree": "ff3d2b15264d6a8fec4b7780d80fc8ca79a997f4",
  "parents": [
    "cfbf8d4857c26a8a307fb7cd258074c9dcd8c691"
  ],
  "author": {
    "name": "Alex Williamson",
    "email": "alex.williamson@redhat.com",
    "time": "Wed Feb 26 11:38:36 2014 -0700"
  },
  "committer": {
    "name": "Alex Williamson",
    "email": "alex.williamson@redhat.com",
    "time": "Wed Feb 26 11:38:36 2014 -0700"
  },
  "message": "vfio/iommu_type1: Multi-IOMMU domain support\n\nWe currently have a problem that we cannot support advanced features\nof an IOMMU domain (ex. IOMMU_CACHE), because we have no guarantee\nthat those features will be supported by all of the hardware units\ninvolved with the domain over its lifetime.  For instance, the Intel\nVT-d architecture does not require that all DRHDs support snoop\ncontrol.  If we create a domain based on a device behind a DRHD that\ndoes support snoop control and enable SNP support via the IOMMU_CACHE\nmapping option, we cannot then add a device behind a DRHD which does\nnot support snoop control or we\u0027ll get reserved bit faults from the\nSNP bit in the pagetables.  To add to the complexity, we can\u0027t know\nthe properties of a domain until a device is attached.\n\nWe could pass this problem off to userspace and require that a\nseparate vfio container be used, but we don\u0027t know how to handle page\naccounting in that case.  How do we know that a page pinned in one\ncontainer is the same page as a different container and avoid double\nbilling the user for the page.\n\nThe solution is therefore to support multiple IOMMU domains per\ncontainer.  In the majority of cases, only one domain will be required\nsince hardware is typically consistent within a system.  However, this\nprovides us the ability to validate compatibility of domains and\nsupport mixed environments where page table flags can be different\nbetween domains.\n\nTo do this, our DMA tracking needs to change.  We currently try to\ncoalesce user mappings into as few tracking entries as possible.  The\nproblem then becomes that we lose granularity of user mappings.  We\u0027ve\nnever guaranteed that a user is able to unmap at a finer granularity\nthan the original mapping, but we must honor the granularity of the\noriginal mapping.  This coalescing code is therefore removed, allowing\nonly unmaps covering complete maps.  The change in accounting is\nfairly small here, a typical QEMU VM will start out with roughly a\ndozen entries, so it\u0027s arguable if this coalescing was ever needed.\n\nWe also move IOMMU domain creation to the point where a group is\nattached to the container.  An interesting side-effect of this is that\nwe now have access to the device at the time of domain creation and\ncan probe the devices within the group to determine the bus_type.\nThis finally makes vfio_iommu_type1 completely device/bus agnostic.\nIn fact, each IOMMU domain can host devices on different buses managed\nby different physical IOMMUs, and present a single DMA mapping\ninterface to the user.  When a new domain is created, mappings are\nreplayed to bring the IOMMU pagetables up to the state of the current\ncontainer.  And of course, DMA mapping and unmapping automatically\ntraverse all of the configured IOMMU domains.\n\nSigned-off-by: Alex Williamson \u003calex.williamson@redhat.com\u003e\nCc: Varun Sethi \u003cVarun.Sethi@freescale.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "4fb7a8f83c8a99ff8d3412a5328b2407c98409a8",
      "old_mode": 33188,
      "old_path": "drivers/vfio/vfio_iommu_type1.c",
      "new_id": "8c7bb9befdab574622af413f68d555d6822a9cfa",
      "new_mode": 33188,
      "new_path": "drivers/vfio/vfio_iommu_type1.c"
    },
    {
      "type": "modify",
      "old_id": "0fd47f5bc146d2765b3bd2026fb183ff54142be2",
      "old_mode": 33188,
      "old_path": "include/uapi/linux/vfio.h",
      "new_id": "460fdf2e26f10864a981b7ad08d6449fb5569c06",
      "new_mode": 33188,
      "new_path": "include/uapi/linux/vfio.h"
    }
  ]
}