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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <165541020563.1955826.16350888595945658159.stgit@omen>
Date:   Thu, 16 Jun 2022 14:38:39 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     corbet@....net, maarten.lankhorst@...ux.intel.com,
        mripard@...nel.org, tzimmermann@...e.de, airlied@...ux.ie,
        daniel@...ll.ch, deller@....de, gregkh@...uxfoundation.org
Cc:     Laszlo Ersek <lersek@...hat.com>,
        Gerd Hoffmann <kraxel@...hat.com>, linux-doc@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: [PATCH v2 0/2] Improve vfio-pci primary GPU assignment behavior

When assigning a primary graphics device to VM through vfio-pci device
assignment, users often prevent binding of the native PCI graphics
driver to avoid device initialization conflicts, however firmware
console drivers may still be attached to the device which can often be
cumbersome to manually unbind or exclude via cmdline options.

This series proposes to move the DRM aperture helpers out to
drivers/video/ to make it more accessible to drivers like vfio-pci,
which have neither dependencies on DRM code nor a struct drm_driver
to present to existing interfaces.  vfio-pci can then trivially call
into the aperture helpers to remove conflicting drivers, rather than
open coding it ourselves as was proposed with a new symbol export in
v1 of this series[1].

Thanks to Thomas for splitting out the aperture code with new
documentation.

Thomas had proposed this going through the vfio tree with appropriate
stakeholder acks, that's fine with me, but I'm also open to it going
through the DRM tree given that the vfio-pci-core change is even more
trivial now and the bulk of the changes are DRM/video paths.  Thanks,

Alex

[1]https://lore.kernel.org/all/165453797543.3592816.6381793341352595461.stgit@omen/

---

Alex Williamson (1):
      vfio/pci: Remove console drivers

Thomas Zimmermann (1):
      drm: Implement DRM aperture helpers under video/


 Documentation/driver-api/aperture.rst |  13 +
 Documentation/driver-api/index.rst    |   1 +
 drivers/gpu/drm/drm_aperture.c        | 174 +------------
 drivers/gpu/drm/tiny/Kconfig          |   1 +
 drivers/vfio/pci/vfio_pci_core.c      |   5 +
 drivers/video/Kconfig                 |   6 +
 drivers/video/Makefile                |   2 +
 drivers/video/aperture.c              | 340 ++++++++++++++++++++++++++
 drivers/video/console/Kconfig         |   1 +
 drivers/video/fbdev/Kconfig           |   7 +-
 include/linux/aperture.h              |  56 +++++
 11 files changed, 440 insertions(+), 166 deletions(-)
 create mode 100644 Documentation/driver-api/aperture.rst
 create mode 100644 drivers/video/aperture.c
 create mode 100644 include/linux/aperture.h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ