25 Sep, 2014

5 commits

  • iommu_bus_init() registers a bus notifier on the given bus by using
    a statically defined notifier block:

    static struct notifier_block iommu_bus_nb = {
    .notifier_call = iommu_bus_notifier,
    };

    This same notifier block is used for all busses. This causes a
    problem for notifiers registered after iommu has registered this
    callback on multiple busses. The problem is that a subsequent
    notifier being registered on a bus which has this iommu notifier
    will also get linked in to the notifier list of all other busses
    which have this iommu notifier.

    This patch fixes this by allocating the notifier_block at runtime.
    Some error checking is also added to catch any allocation failure
    or notifier registration error.

    Signed-off-by: Mark Salter
    Signed-off-by: Joerg Roedel

    Mark Salter
     
  • It turns out that our assumption that aliases are always to the same
    slot isn't true. One particular platform reports an IVRS alias of the
    SATA controller (00:11.0) for the legacy IDE controller (00:14.1).
    When we hit this, we attempt to use a single IOMMU group for
    everything on the same bus, which in this case is the root complex.
    We already have multiple groups defined for the root complex by this
    point, resulting in multiple WARN_ON hits.

    This patch makes these sorts of aliases work again with IOMMU groups
    by reworking how we search through the PCI address space to find
    existing groups. This should also now handle looped dependencies and
    all sorts of crazy inter-dependencies that we'll likely never see.

    The recursion used here should never be very deep. It's unlikely to
    have individual aliases and only theoretical that we'd ever see a
    chain where one alias causes us to search through to yet another
    alias. We're also only dealing with PCIe device on a single bus,
    which means we'll typically only see multiple slots in use on the root
    complex. Loops are also a theoretically possibility, which I've
    tested using fake DMA alias quirks and prevent from causing problems
    using a bitmap of the devfn space that's been visited.

    Signed-off-by: Alex Williamson
    Cc: stable@vger.kernel.org # 3.17
    Signed-off-by: Joerg Roedel

    Alex Williamson
     
  • Signed-off-by: Joerg Roedel

    Joerg Roedel
     
  • This function will replace the current iommu_domain_has_cap
    function and clean up the interface while at it.

    Signed-off-by: Joerg Roedel

    Joerg Roedel
     
  • Allow compile-time type-checking.

    Signed-off-by: Joerg Roedel

    Joerg Roedel
     

26 Aug, 2014

1 commit

  • When a non-PCI device is passed to that function it might
    pass group == NULL to iommu_group_add_device() which then
    dereferences it and cause a crash this way. Fix it by
    just returning an error for non-PCI devices.

    Fixes: 104a1c13ac66e40cf8c6ae74d76ff14ff24b9b01
    Cc: Alex Williamson
    Acked-by: Alex Williamson
    Signed-off-by: Joerg Roedel

    Joerg Roedel
     

19 Aug, 2014

1 commit


07 Jul, 2014

1 commit


04 Jul, 2014

1 commit

  • Currently each IOMMU driver that supports IOMMU groups has its own
    code for discovering the base device used in grouping. This code
    is generally not specific to the IOMMU hardware, but to the bus of
    the devices managed by the IOMMU. We can therefore create a common
    interface for supporting devices on different buses.

    Signed-off-by: Alex Williamson
    Signed-off-by: Joerg Roedel

    Alex Williamson
     

01 Nov, 2013

1 commit


24 Sep, 2013

8 commits

  • Commit 6197ca82 (iommu: Use %pa and %zx instead of casting) introduced the
    usage of '%pa', but still kept the '0x', which leads to printing '0x0x'.

    Remove the '0x' when '%pa' is used.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Joerg Roedel

    Fabio Estevam
     
  • Change iommu driver to call unmap trace event. This iommu_map_unmap class
    event can be enabled to trigger when iommu unmap iommu ops is called. Trace
    information includes iova, physical address (map event only), and size.

    Testing:
    Added trace calls to iommu_prepare_identity_map() for testing some of the
    conditions that are hard to trigger. Here is the trace from the testing:

    swapper/0-1 [003] .... 1.854102: unmap: IOMMU: iova=0x00000000cb800000 size=0x400

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     
  • Change iommu driver to call map trace event. This iommu_map_unmap class event
    can be enabled to trigger when iommu map iommu ops is called. Trace information
    includes iova, physical address (map event only), and size.

    Testing:
    Added trace calls to iommu_prepare_identity_map() for testing some of the
    conditions that are hard to trigger. Here is the trace from the testing:

    swapper/0-1 [003] .... 1.854102: map: IOMMU: iova=0x00000000cb800000 paddr=0x00000000cf9fffff size=0x400

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     
  • Change iommu driver to call detach_device_to_domain trace event. This
    iommu_device class event can be enabled to trigger when devices are detached
    from a domain. Trace information includes device name.

    Testing:
    Added trace calls to iommu_prepare_identity_map() for testing some of the
    conditions that are hard to trigger. Here is the trace from the testing:

    swapper/0-1 [003] .... 1.854102: detach_device_from_domain: IOMMU: device=0000:00:02.0

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     
  • Change iommu driver to call attach_device_to_domain trace event. This
    iommu_device class event can be enabled to trigger when devices are attached
    to a domain. Trace information includes device name.

    Testing:
    Added trace calls to iommu_prepare_identity_map() for testing some of the
    conditions that are hard to trigger. Here is the trace from the testing:

    swapper/0-1 [003] .... 1.854102: attach_device_to_domain: IOMMU: device=0000:00:02.0

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     
  • Change iommu driver to call remove_device_to_group trace event. This
    iommu_group class event can be enabled to trigger when devices get
    removed from an iommu group. Trace information includes iommu group id and
    device name.

    Testing:
    Added trace calls to iommu_prepare_identity_map() for testing some of the
    conditions that are hard to trigger. Here is the trace from the testing:

    swapper/0-1 [003] .... 1.854101: remove_device_from_group: IOMMU: groupID=0 device=0000:00:02.0

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     
  • Change iommu driver to call add_device_to_group trace event. This iommu_group
    class event can be enabled to trigger when devices get added to an iommu group.
    Trace information includes iommu group id and device name.

    Testing:
    The following is trace is generated when intel-iommu driver adds devices to
    to iommu groups during boot-time during its initialization:

    swapper/0-1 [003] .... 1.854793: add_device_to_group: IOMMU: groupID=0 device=0000:00:00.0
    swapper/0-1 [003] .... 1.854797: add_device_to_group: IOMMU: groupID=1 device=0000:00:02.0

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     
  • Add tracing feature to iommu to report various iommu events. Classes
    iommu_group, iommu_device, and iommu_map_unmap are defined.

    iommu_group class events can be enabled to trigger when devices get added
    to and removed from an iommu group. Trace information includes iommu group
    id and device name.

    iommu:add_device_to_group
    iommu:remove_device_from_group

    iommu_device class events can be enabled to trigger when devices are attached
    to and detached from a domain. Trace information includes device name.

    iommu:attach_device_to_domain
    iommu:detach_device_from_domain

    iommu_map_unmap class events can be enabled to trigger when iommu map and
    unmap iommu ops. Trace information includes iova, physical address (map event
    only), and size.

    iommu:map
    iommu:unmap

    Signed-off-by: Shuah Khan
    Signed-off-by: Joerg Roedel

    Shuah Khan
     

24 Jun, 2013

1 commit

  • printk supports using %pa for phys_addr_t and
    %zx for size_t so use those instead of %lx and
    casts to unsigned long.

    Other miscellaneous changes around this:

    Always use 0x%zx for size instead of one use of decimal.
    Coalesce format and align arguments.

    Signed-off-by: Joe Perches
    Signed-off-by: Joerg Roedel

    Joe Perches
     

23 Jun, 2013

1 commit


20 Jun, 2013

1 commit

  • iommu_map splits requests into pages that the iommu driver reports
    that it can handle. The iommu_unmap path does not do the same. This
    can cause problems not only from callers that might expect the same
    behavior as the map path, but even from the failure path of iommu_map,
    should it fail at a point where it has mapped and needs to unwind a
    set of pages that the iommu driver cannot handle directly. amd_iommu,
    for example, will BUG_ON if asked to unmap a non power of 2 size.

    Fix this by extracting and generalizing the sizing code from the
    iommu_map path and use it for both map and unmap.

    Signed-off-by: Alex Williamson
    Signed-off-by: Joerg Roedel

    Alex Williamson
     

02 May, 2013

1 commit


25 Apr, 2013

1 commit

  • As IOMMU groups are exposed to the user space by their numbers,
    the user space can use them in various kernel APIs so the kernel
    might need an API to find a group by its ID.

    As an example, QEMU VFIO on PPC64 platform needs it to associate
    a logical bus number (LIOBN) with a specific IOMMU group in order
    to support in-kernel handling of DMA map/unmap requests.

    The patch adds the iommu_group_get_by_id(id) function which performs
    such search.

    v2: fixed reference counting.

    Signed-off-by: Alexey Kardashevskiy
    Acked-by: Alex Williamson
    Signed-off-by: Joerg Roedel

    Alexey Kardashevskiy
     

03 Apr, 2013

2 commits


06 Feb, 2013

4 commits


11 Jan, 2013

1 commit

  • The iommu_init() initializes IOMMU internal structures and data
    required for the IOMMU API as iommu_group_alloc().
    It is registered as a subsys_initcall now.

    One of the IOMMU users is going to be a PCI subsystem on POWER.
    It discovers new IOMMU tables during the PCI scan so the logical
    place to call iommu_group_alloc() is the moment when a new group
    is discovered. However PCI scan is done from subsys_initcall hook
    as IOMMU does so PCI hook can be (and is) called before the IOMMU one.

    The patch moves IOMMU subsystem initialization one step earlier
    to make sure that IOMMU is initialized before PCI scan begins.

    Signed-off-by: Alexey Kardashevskiy
    Signed-off-by: Joerg Roedel

    Alexey Kardashevskiy
     

23 Jul, 2012

1 commit


11 Jul, 2012

2 commits


25 Jun, 2012

1 commit

  • IOMMU device groups are currently a rather vague associative notion
    with assembly required by the user or user level driver provider to
    do anything useful. This patch intends to grow the IOMMU group concept
    into something a bit more consumable.

    To do this, we first create an object representing the group, struct
    iommu_group. This structure is allocated (iommu_group_alloc) and
    filled (iommu_group_add_device) by the iommu driver. The iommu driver
    is free to add devices to the group using it's own set of policies.
    This allows inclusion of devices based on physical hardware or topology
    limitations of the platform, as well as soft requirements, such as
    multi-function trust levels or peer-to-peer protection of the
    interconnects. Each device may only belong to a single iommu group,
    which is linked from struct device.iommu_group. IOMMU groups are
    maintained using kobject reference counting, allowing for automatic
    removal of empty, unreferenced groups. It is the responsibility of
    the iommu driver to remove devices from the group
    (iommu_group_remove_device).

    IOMMU groups also include a userspace representation in sysfs under
    /sys/kernel/iommu_groups. When allocated, each group is given a
    dynamically assign ID (int). The ID is managed by the core IOMMU group
    code to support multiple heterogeneous iommu drivers, which could
    potentially collide in group naming/numbering. This also keeps group
    IDs to small, easily managed values. A directory is created under
    /sys/kernel/iommu_groups for each group. A further subdirectory named
    "devices" contains links to each device within the group. The iommu_group
    file in the device's sysfs directory, which formerly contained a group
    number when read, is now a link to the iommu group. Example:

    $ ls -l /sys/kernel/iommu_groups/26/devices/
    total 0
    lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
    ../../../../devices/pci0000:00/0000:00:1e.0
    lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
    ../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
    lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
    ../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1

    $ ls -l /sys/kernel/iommu_groups/26/devices/*/iommu_group
    [truncating perms/owner/timestamp]
    /sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
    ../../../kernel/iommu_groups/26
    /sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
    ../../../../kernel/iommu_groups/26
    /sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
    ../../../../kernel/iommu_groups/26

    Groups also include several exported functions for use by user level
    driver providers, for example VFIO. These include:

    iommu_group_get(): Acquires a reference to a group from a device
    iommu_group_put(): Releases reference
    iommu_group_for_each_dev(): Iterates over group devices using callback
    iommu_group_[un]register_notifier(): Allows notification of device add
    and remove operations relevant to the group
    iommu_group_id(): Return the group number

    This patch also extends the IOMMU API to allow attaching groups to
    domains. This is currently a simple wrapper for iterating through
    devices within a group, but it's expected that the IOMMU API may
    eventually make groups a more integral part of domains.

    Groups intentionally do not try to manage group ownership. A user
    level driver provider must independently acquire ownership for each
    device within a group before making use of the group as a whole.
    This may change in the future if group usage becomes more pervasive
    across both DMA and IOMMU ops.

    Groups intentionally do not provide a mechanism for driver locking
    or otherwise manipulating driver matching/probing of devices within
    the group. Such interfaces are generic to devices and beyond the
    scope of IOMMU groups. If implemented, user level providers have
    ready access via iommu_group_for_each_dev and group notifiers.

    iommu_device_group() is removed here as it has no users. The
    replacement is:

    group = iommu_group_get(dev);
    id = iommu_group_id(group);
    iommu_group_put(group);

    AMD-Vi & Intel VT-d support re-added in following patches.

    Signed-off-by: Alex Williamson
    Acked-by: Benjamin Herrenschmidt
    Signed-off-by: Joerg Roedel

    Alex Williamson
     

23 May, 2012

1 commit

  • Sometimes a single IOMMU user may have to deal with several
    different IOMMU devices (e.g. remoteproc).

    When an IOMMU fault happens, such users have to regain their
    context in order to deal with the fault.

    Users can't use the private fields of neither the iommu_domain nor
    the IOMMU device, because those are already used by the IOMMU core
    and low level driver (respectively).

    This patch just simply allows users to pass a private token (most
    notably their own context pointer) to iommu_set_fault_handler(),
    and then makes sure it is provided back to the users whenever
    an IOMMU fault happens.

    The patch also adopts remoteproc to the new fault handling
    interface, but the real functionality using this (recovery of
    remote processors) will only be added later in a subsequent patch
    set.

    Cc: Fernando Guzman Lugo
    Signed-off-by: Ohad Ben-Cohen
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen
     

09 Jan, 2012

2 commits


16 Dec, 2011

1 commit


15 Nov, 2011

1 commit

  • An IOMMU group is a set of devices for which the IOMMU cannot
    distinguish transactions. For PCI devices, a group often occurs
    when a PCI bridge is involved. Transactions from any device
    behind the bridge appear to be sourced from the bridge itself.
    We leave it to the IOMMU driver to define the grouping restraints
    for their platform.

    Using this new interface, the group for a device can be retrieved
    using the iommu_device_group() callback. Users will compare the
    value returned against the value returned for other devices to
    determine whether they are part of the same group. Devices with
    no group are not translated by the IOMMU. There should be no
    expectations about the group numbers as they may be arbitrarily
    assigned by the IOMMU driver and may not be persistent across boots.

    We also provide a sysfs interface to the group numbers here so
    that userspace can understand IOMMU dependencies between devices
    for managing safe, userspace drivers.

    [Some code changes by Joerg Roedel ]

    Signed-off-by: Alex Williamson
    Signed-off-by: Joerg Roedel

    Alex Williamson
     

10 Nov, 2011

1 commit