Skip to content

L
linux
Switch branch/tag
  1. 28 Apr, 2016 3 commits
    • Alexey Kardashevskiy's avatar
      vfio_iommu_spapr_tce: Remove unneeded iommu_group_get_iommudata · 5ed4aba1
      Alexey Kardashevskiy authored 
      This removes iommu_group_get_iommudata() as the result is never used.
As this is a minor cleanup, no change in behavior is expected.
Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      5ed4aba1
    • Alex Williamson's avatar
      vfio/pci: Add test for BAR restore · dc928109
      Alex Williamson authored 
      If a device is reset without the memory or i/o bits enabled in the
command register we may not detect it, potentially leaving the device
without valid BAR programming.  Add an additional test to check the
BARs on each write to the command register.
Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      dc928109
    • Alex Williamson's avatar
      vfio/pci: Hide broken INTx support from user · 45074405
      Alex Williamson authored 
      INTx masking has two components, the first is that we need the ability
to prevent the device from continuing to assert INTx.  This is
provided via the DisINTx bit in the command register and is the only
thing we can really probe for when testing if INTx masking is
supported.  The second component is that the device needs to indicate
if INTx is asserted via the interrupt status bit in the device status
register.  With these two features we can generically determine if one
of the devices we own is asserting INTx, signal the user, and mask the
interrupt while the user services the device.

Generally if one or both of these components is broken we resort to
APIC level interrupt masking, which requires an exclusive interrupt
since we have no way to determine the source of the interrupt in a
shared configuration.  This often makes it difficult or impossible to
configure the system for userspace use of the device, for an interrupt
mode that the user may not need.

One possible configuration of broken INTx masking is that the DisINTx
support is fully functional, but the interrupt status bit never
signals interrupt assertion.  In this case we do have the ability to
prevent the device from asserting INTx, but lack the ability to
identify the interrupt source.  For this case we can simply pretend
that the device lacks INTx support entirely, keeping DisINTx set on
the physical device, virtualizing this bit for the user, and
virtualizing the interrupt pin register to indicate no INTx support.
We already support virtualization of the DisINTx bit and already
virtualize the interrupt pin for platforms without INTx support.  By
tying these components together, setting DisINTx on open and reset,
and identifying devices broken in this particular way, we can provide
support for them w/o the handicap of APIC level INTx masking.

Intel i40e (XL710/X710) 10/20/40GbE NICs have been identified as being
broken in this specific way.  We leave the vfio-pci.nointxmask option
as a mechanism to bypass this support, enabling INTx on the device
with all the requirements of APIC level masking.
Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
Cc: John Ronciak <john.ronciak@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      45074405
  3. 24 Apr, 2016 2 commits
  5. 23 Apr, 2016 10 commits
  7. 22 Apr, 2016 24 commits
  9. 21 Apr, 2016 1 commit
    • cpaul@redhat.com's avatar
      drm/dp/mst: Validate port in drm_dp_payload_send_msg() · deba0a2a
      cpaul@redhat.com authored 
      With the joys of things running concurrently, there's always a chance
that the port we get passed in drm_dp_payload_send_msg() isn't actually
valid anymore. Because of this, we need to make sure we validate the
reference to the port before we use it otherwise we risk running into
various race conditions. For instance, on the Dell MST monitor I have
here for testing, hotplugging it enough times causes us to kernel panic:

[drm:intel_mst_enable_dp] 1
[drm:drm_dp_update_payload_part2] payload 0 1
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
[drm:intel_hpd_irq_handler] digital hpd port B - short
[drm:intel_dp_hpd_pulse] got hpd irq on port B - short
[drm:intel_dp_check_mst_status] got esi 00 10 00
[drm:drm_dp_update_payload_part2] payload 1 1
general protection fault: 0000 [#1] SMP
…
Call Trace:
 [<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
 [<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
 [<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
 [<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
 [<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
 [<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
 [<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
 [<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
 [<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
 [<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
 [<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
 [<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
 [<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
 [<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
 [<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
 [<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
RIP  [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]

Which occurs because of the hotplug event shown in the log, which ends
up causing DRM's dp helpers to drop the port we're updating the payload
on and panic.

CC: stable@vger.kernel.org
Signed-off-by: default avatarLyude <cpaul@redhat.com>
Reviewed-by: default avatarDavid Airlie <airlied@linux.ie>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      deba0a2a
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7