[Intel-gfx] [PATCH v8 20/24] vfio: Add cdev for vfio_device

This allows user to directly open a vfio device w/o using the legacy container/group interface, as a prerequisite for supporting new iommu features like nested translation. The device fd opened in this manner doesn't have the capability to access the device as the fops open() doesn't open the

[Intel-gfx] [PATCH v8 14/24] vfio: Record devid in vfio_device_file

.bind_iommufd() will generate an ID to represent this bond, which is needed by userspace for further usage. Store devid in vfio_device_file to avoid passing the pointer in multiple places. Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu --- drivers/vfio/iommufd.c | 12

[Intel-gfx] [PATCH v8 24/24] docs: vfio: Add vfio device cdev description

This gives notes for userspace applications on device cdev usage. Reviewed-by: Kevin Tian Signed-off-by: Yi Liu --- Documentation/driver-api/vfio.rst | 127 ++ 1 file changed, 127 insertions(+) diff --git a/Documentation/driver-api/vfio.rst

[Intel-gfx] [PATCH v8 18/24] vfio: Determine noiommu in vfio_device registration

This adds a noiommu flag in vfio_device, hence caller of the vfio_device_is_noiommu() just refers to the flag for noiommu check. Signed-off-by: Yi Liu --- drivers/vfio/group.c | 2 +- drivers/vfio/vfio.h | 6 +++--- drivers/vfio/vfio_main.c | 2 ++ include/linux/vfio.h | 1 + 4

[Intel-gfx] [PATCH v8 19/24] vfio: Name noiommu vfio_device with "noiommu-" prefix

For noiommu device, vfio core names the cdev node with prefix "noiommu-". Signed-off-by: Yi Liu --- drivers/vfio/vfio_main.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c index 805c34c7b0ef..8e96aab27029 100644

[Intel-gfx] [PATCH v8 02/24] vfio: Refine vfio file kAPIs for KVM

This prepares for making the below kAPIs to accept both group file and device file instead of only vfio group file. bool vfio_file_enforced_coherent(struct file *file); void vfio_file_set_kvm(struct file *file, struct kvm *kvm); Reviewed-by: Kevin Tian Reviewed-by: Eric Auger Reviewed-by:

[Intel-gfx] [PATCH v8 11/24] vfio: Make vfio_device_first_open() to accept NULL iommufd for noiommu

vfio_device_first_open() requires the caller to provide either a valid iommufd (the group path in iommufd compat mode) or a valid container (the group path in legacy container mode). As preparation for noiommu support in device cdev path it's extended to allow both being NULL. The caller is

[Intel-gfx] [PATCH v8 08/24] vfio: Block device access via device fd until device is opened

Allow the vfio_device file to be in a state where the device FD is opened but the device cannot be used by userspace (i.e. its .open_device() hasn't been called). This inbetween state is not used when the device FD is spawned from the group FD, however when we create the device FD directly by

[Intel-gfx] [PATCH v8 09/24] vfio: Add cdev_device_open_cnt to vfio_group

for counting the devices that are opened via the cdev path. This count is increased and decreased by the cdev path. The group path checks it to achieve exclusion with the cdev path. With this, only one path (group path or cdev path) will claim DMA ownership. This avoids scenarios in which devices

[Intel-gfx] [PATCH v8 12/24] vfio-iommufd: Move noiommu support out of vfio_iommufd_bind()

into vfio_device_group_open(). This is also more consistent with what will be done in vfio device cdev path. Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu --- drivers/vfio/group.c | 9 + drivers/vfio/iommufd.c | 35 ++-

[Intel-gfx] [PATCH v8 10/24] vfio: Make vfio_device_open() single open for device cdev path

VFIO group has historically allowed multi-open of the device FD. This was made secure because the "open" was executed via an ioctl to the group FD which is itself only single open. However, no known use of multiple device FDs today. It is kind of a strange thing to do because new device FDs can

[Intel-gfx] [PATCH v8 13/24] vfio-iommufd: Split bind/attach into two steps

to align with the coming vfio device cdev support. Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu --- drivers/vfio/group.c | 18 ++ drivers/vfio/iommufd.c | 33 ++--- drivers/vfio/vfio.h| 9 + 3 files changed, 37

[Intel-gfx] [PATCH v8 05/24] kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd

Meanwhile, rename related helpers. No functional change is intended. Reviewed-by: Kevin Tian Reviewed-by: Eric Auger Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Signed-off-by: Yi Liu --- virt/kvm/vfio.c | 115

[Intel-gfx] [PATCH v8 06/24] kvm/vfio: Accept vfio device file from userspace

This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*. Old userspace uses KVM_DEV_VFIO_GROUP* works as well. Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Signed-off-by: Yi Liu ---

[Intel-gfx] [PATCH v8 07/24] vfio: Pass struct vfio_device_file * to vfio_device_open/close()

This avoids passing too much parameters in multiple functions. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Signed-off-by: Yi Liu --- drivers/vfio/group.c | 20 ++-- drivers/vfio/vfio.h

[Intel-gfx] [PATCH v8 04/24] vfio: Accept vfio device file in the KVM facing kAPI

This makes the vfio file kAPIs to accept vfio device files, also a preparation for vfio device cdev support. For the kvm set with vfio device file, kvm pointer is stored in struct vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm pointer usage within VFIO. This kvm pointer will be

[Intel-gfx] [PATCH v8 01/24] vfio: Allocate per device file structure

This is preparation for adding vfio device cdev support. vfio device cdev requires: 1) A per device file memory to store the kvm pointer set by KVM. It will be propagated to vfio_device:kvm after the device cdev file is bound to an iommufd. 2) A mechanism to block device access through

[Intel-gfx] [PATCH v8 03/24] vfio: Remove vfio_file_is_group()

since no user of vfio_file_is_group() now. Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu --- drivers/vfio/group.c | 10 -- include/linux/vfio.h | 1 - 2 files changed, 11 deletions(-) diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c index

[Intel-gfx] [PATCH v8 00/24] Add vfio_device cdev for iommufd support

Existing VFIO provides group-centric user APIs for userspace. Userspace opens the /dev/vfio/$group_id first before getting device fd and hence getting access to device. This is not the desired model for iommufd. Per the conclusion of community discussion[1], iommufd provides device-centric kAPIs

[Intel-gfx] [PATCH v2 03/10] vfio/pci: Move the existing hot reset logic to be a helper

This prepares to add another method for hot reset. The major hot reset logic are moved to vfio_pci_ioctl_pci_hot_reset_groups(). No functional change is intended. Suggested-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 56

[Intel-gfx] [PATCH v2 05/10] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

as an alternative method for ownership check when iommufd is used. In this case all opened devices in the affected dev_set are verified to be bound to a same valid iommufd value to allow reset. It's simpler and faster as user does not need to pass a set of fds and kernel no need to search the

[Intel-gfx] [PATCH v2 04/10] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device

This is needed by the vfio pci driver to report affected devices in the hot reset for a given device. Signed-off-by: Yi Liu --- drivers/iommu/iommufd/device.c | 12 drivers/vfio/iommufd.c | 16 include/linux/iommufd.h| 3 +++ include/linux/vfio.h

[Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO

This is a preparation for vfio device cdev as cdev gives userspace the capability to open device cdev fd and management stack (e.g. libvirt) could pass the device fd to the actual user (e.g. QEMU). As a result, the actual user has no idea about the device's bus:devfn information. This is a problem

[Intel-gfx] [PATCH v2 07/10] vfio: Accpet device file from vfio PCI hot reset path

This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept device file from the vfio PCI hot reset. Reviewed-by: Kevin Tian Signed-off-by: Yi Liu --- drivers/vfio/vfio_main.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH v2 09/10] vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl

Now user can also provide an array of device fds as a 3rd method to verify the reset ownership. It's not useful at this point when the device fds are acquired via group fds. But it's necessary when moving to device cdev which allows the user to directly acquire device fds by skipping group. In

[Intel-gfx] [PATCH v2 08/10] vfio/pci: Renaming for accepting device fd in hot reset path

No functional change is intended. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 52 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/drivers/vfio/pci/vfio_pci_core.c

[Intel-gfx] [PATCH v2 06/10] vfio: Refine vfio file kAPIs for vfio PCI hot reset

This prepares vfio core to accept vfio device file from the vfio PCI hot reset path. vfio_file_is_group() is still kept for KVM usage. Reviewed-by: Kevin Tian Signed-off-by: Yi Liu --- drivers/vfio/group.c | 32 ++-- drivers/vfio/pci/vfio_pci_core.c | 4

[Intel-gfx] [PATCH v2 02/10] vfio/pci: Only check ownership of opened devices in hot reset

If the affected device is not opened by any user, it's safe to reset it given it's not in use. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 14 +++--- include/uapi/linux/vfio.h| 8 2 files changed,

[Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset

VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to prove that it owns all devices affected by resetting the calling device. This series introduces several extensions to allow the ownership check better aligned with iommufd and coming vfio device cdev support. First,

[Intel-gfx] [PATCH v2 01/10] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()

this suits more on what the code does. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c

[Intel-gfx] [PATCH v3 3/6] vfio-iommufd: No need to record iommufd_ctx in vfio_device

iommufd_ctx is stored in vfio_device for emulated devices per bind_iommufd. However, as iommufd_access is created in bind, no more need to stored it since iommufd_access implicitly stores it. Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu ---

[Intel-gfx] [PATCH v3 6/6] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()

After making the no-DMA drivers (samples/vfio-mdev) providing iommufd callbacks, __vfio_register_dev() should check the presence of the iommufd callbacks if CONFIG_IOMMUFD is enabled. Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu ---

[Intel-gfx] [PATCH v3 4/6] vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID

vfio device cdev needs to return iommufd_access ID to userspace if bind_iommufd succeeds. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Signed-off-by: Yi Liu --- drivers/iommu/iommufd/device.c | 4 +++- drivers/iommu/iommufd/selftest.c | 3 ++-

[Intel-gfx] [PATCH v3 5/6] vfio/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers

This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add BIND_IOMMUFD user interface which requires to return an iommufd ID to represent the device/iommufd bond. Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin

[Intel-gfx] [PATCH v3 1/6] iommu/iommufd: Pass iommufd_ctx pointer in iommufd_get_ioas()

no need to pass the iommufd_ucmd pointer. Signed-off-by: Yi Liu --- drivers/iommu/iommufd/ioas.c| 14 +++--- drivers/iommu/iommufd/iommufd_private.h | 4 ++-- drivers/iommu/iommufd/selftest.c| 6 +++--- drivers/iommu/iommufd/vfio_compat.c | 2 +- 4 files

[Intel-gfx] [PATCH v3 2/6] iommufd: Create access in vfio_iommufd_emulated_bind()

From: Nicolin Chen There are needs to created iommufd_access prior to have an IOAS and set IOAS later. Like the vfio device cdev needs to have an iommufd object to represent the bond (iommufd_access) and IOAS replacement. Moves the iommufd_access_create() call into vfio_iommufd_emulated_bind(),

[Intel-gfx] [PATCH v3 0/6] vfio: Make emulated devices prepared for vfio device cdev

The .bind_iommufd op of vfio emulated devices are either empty or does nothing. This is different with the vfio physical devices, to add vfio device cdev, need to make them act the same. This series first makes the .bind_iommufd op of vfio emulated devices to create iommufd_access, this

Re: [Intel-gfx] [PATCH] drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC

Change looks good to me. I think it will be good to add Fixes tag. Regards, Ankit On 3/27/2023 12:12 PM, Stanislav Lisovskiy wrote: For obvious reasons, we use compressed bpp instead of pipe bpp for DSC DP SST case. Lets be consistent and use compressed bpp instead of pipe bpp, also in DP MST

Re: [Intel-gfx] [PATCH v5 09/22] drm/i915/mtl: C20 HW readout

On Thu, Mar 16, 2023 at 01:13:22PM +0200, Mika Kahola wrote: > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates. > The PLL settings are based on table, not for algorithmic alternative. > For DP 1.4 only MPLLB is in use. > > Once register settings are done, we read back C20 HW state. > >

Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout

On Fri, Mar 24, 2023 at 05:51:11PM -0300, Gustavo Sousa wrote: > On Thu, Feb 23, 2023 at 06:47:27AM -0300, Kahola, Mika wrote: > > > > [...] > > > > +void intel_c20pll_readout_hw_state(struct intel_encoder *encoder, > > > > + struct intel_c20pll_state > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC

On Mon, 2023-03-27 at 09:42 +0300, Stanislav Lisovskiy wrote: > For obvious reasons, we use compressed bpp instead of pipe bpp for > DSC DP SST case. Lets be consistent and use compressed bpp instead of > pipe bpp, also in DP MST DSC case. > > Signed-off-by: Stanislav Lisovskiy > --- >  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Program pipe A PIPE_MISC_A bit 9 Pixel Extension to 0

== Series Details == Series: drm/i915/display: Program pipe A PIPE_MISC_A bit 9 Pixel Extension to 0 URL : https://patchwork.freedesktop.org/series/115652/ State : success == Summary == CI Bug Log - changes from CI_DRM_12914 -> Patchwork_115652v1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC

== Series Details == Series: drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC URL : https://patchwork.freedesktop.org/series/115649/ State : success == Summary == CI Bug Log - changes from CI_DRM_12914_full -> Patchwork_115649v1_full

[Intel-gfx] [PATCH] drm/i915/display: Program pipe A PIPE_MISC_A bit 9 Pixel Extension to 0

From: Jigar Bhatt Due to RTL bug FBC cannot be enabled when pipe is programed in Pixel Extension mode of Zero Extend. This caused 1 bit change in pixel value in compressed vs uncompressed frame which comes up as a flicker. WA for D13 is to always used MSB Extend for Pixel extension. WA:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Communicate display power demands to pcode (rev3)

== Series Details == Series: drm/i915/display: Communicate display power demands to pcode (rev3) URL : https://patchwork.freedesktop.org/series/115371/ State : success == Summary == CI Bug Log - changes from CI_DRM_12914_full -> Patchwork_115371v3_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC

== Series Details == Series: drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC URL : https://patchwork.freedesktop.org/series/115649/ State : success == Summary == CI Bug Log - changes from CI_DRM_12914 -> Patchwork_115649v1

Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup

On 26/03/2023 14:18, Rodrigo Vivi wrote: On Sat, Mar 25, 2023 at 02:19:21AM -0400, Teres Alexis, Alan Previn wrote: alan:snip @@ -353,8 +367,20 @@ int intel_pxp_start(struct intel_pxp *pxp) alan:snip + if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) { + /* +* GSC-fw

[Intel-gfx] [PATCH] drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC

For obvious reasons, we use compressed bpp instead of pipe bpp for DSC DP SST case. Lets be consistent and use compressed bpp instead of pipe bpp, also in DP MST DSC case. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- 1 file changed, 1 insertion(+),

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Communicate display power demands to pcode (rev3)

== Series Details == Series: drm/i915/display: Communicate display power demands to pcode (rev3) URL : https://patchwork.freedesktop.org/series/115371/ State : success == Summary == CI Bug Log - changes from CI_DRM_12914 -> Patchwork_115371v3

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Communicate display power demands to pcode (rev3)

== Series Details == Series: drm/i915/display: Communicate display power demands to pcode (rev3) URL : https://patchwork.freedesktop.org/series/115371/ State : warning == Summary == Error: dim checkpatch failed 360f419866ef drm/i915/display: Communicate display power demands to pcode -:9:

<    1   2