Hi Jean,
On 11/23/21 4:52 PM, Jean-Philippe Brucker wrote:
> The VIRTIO_IOMMU_F_BYPASS_CONFIG feature adds a new flag to the ATTACH
> request, that creates a bypass domain. Use it to enable identity
> domains.
>
> When VIRTIO_IOMMU_F_BYPASS_CONFIG is not supported by the device, we
> currently
On Sat, Nov 27, 2021 at 04:07:18PM -0800, Andrew Morton wrote:
>On Fri, 26 Nov 2021 10:47:11 +0800 Calvin Zhang
>wrote:
>
>> Just like this:
>> commit 620951e27457 ("mm/cma: make kmemleak ignore CMA regions").
>>
>> Add kmemleak_ignore_phys() for CMA created from of reserved node.
>
>Could we
On Sat, Nov 27, 2021 at 02:20:09AM +0100, Thomas Gleixner wrote:
> +/**
> + * msi_setup_device_data - Setup MSI device data
> + * @dev: Device for which MSI device data should be set up
> + *
> + * Return: 0 on success, appropriate error code otherwise
> + *
> + * This can be called more than
On Fri, 26 Nov 2021 10:47:11 +0800 Calvin Zhang
wrote:
> Just like this:
> commit 620951e27457 ("mm/cma: make kmemleak ignore CMA regions").
>
> Add kmemleak_ignore_phys() for CMA created from of reserved node.
Could we please have a full, standalone changelog for this patch?
The
On 11/23/21 4:53 PM, Jean-Philippe Brucker wrote:
> To support identity mappings, the virtio-iommu driver must be able to
> represent full 64-bit ranges internally. Pass (start, end) instead of
> (start, size) to viommu_add/del_mapping().
>
> Clean comments. The one about the returned size was
Hi Jean,
On 11/23/21 4:53 PM, Jean-Philippe Brucker wrote:
> To ease identity mapping support, keep the list of reserved regions
> sorted.
>
> Reviewed-by: Kevin Tian
> Signed-off-by: Jean-Philippe Brucker
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/virtio-iommu.c | 9 +++--
> 1
Hi Jean,
On 11/23/21 4:53 PM, Jean-Philippe Brucker wrote:
> Support identity domains for devices that do not offer the
> VIRTIO_IOMMU_F_BYPASS_CONFIG feature, by creating 1:1 mappings between
> the virtual and physical address space. Identity domains created this
> way still perform noticeably
On Sat, Nov 27, 2021 at 06:09:40PM +0100, Eric Auger wrote:
>
>
> On 11/23/21 4:53 PM, Jean-Philippe Brucker wrote:
> > To support identity mappings, the virtio-iommu driver must be able to
> > represent full 64-bit ranges internally. Pass (start, end) instead of
> > (start, size) to
>From the perspective of who is initiating the device to do DMA, device
DMA could be divided into the following types:
DMA_OWNER_DMA_API: Device DMAs are initiated by a kernel driver
through the kernel DMA API.
DMA_OWNER_PRIVATE_DOMAIN: Device DMAs are
The bus_type structure defines dma_configure() callback for bus drivers
to configure DMA on the devices. This adds the paired dma_unconfigure()
callback and calls it during driver unbinding so that bus drivers can do
some cleanup work.
One use case for this paired DMA callbacks is for the bus
Multiple platform devices may be placed in the same IOMMU group because
they cannot be isolated from each other. These devices must either be
entirely under kernel control or userspace control, never a mixture. This
checks and sets DMA ownership during driver binding, and release the
ownership
Multiple amba devices may be placed in the same IOMMU group because
they cannot be isolated from each other. These devices must either be
entirely under kernel control or userspace control, never a mixture. This
checks and sets DMA ownership during driver binding, and release the
ownership during
The vfio needs to set DMA_OWNER_PRIVATE_DOMAIN_USER for the entire group
when attaching it to a vfio container. Expose group variants of setting/
releasing dma ownership for this purpose.
This also exposes the helper iommu_group_dma_owner_unclaimed() for vfio
to report to userspace if the group
Multiple fsl-mc devices may be placed in the same IOMMU group because
they cannot be isolated from each other. These devices must either be
entirely under kernel control or userspace control, never a mixture. This
checks and sets DMA ownership during driver binding, and release the
ownership
Multiple PCI devices may be placed in the same IOMMU group because they
cannot be isolated from each other. These devices must either be entirely
under kernel control or userspace control, never a mixture. This checks
and sets DMA ownership during driver binding, and vice versa, release the
IOMMU grouping on PCI necessitates that if we lack isolation on a bridge
then all of the downstream devices will be part of the same IOMMU group
as the bridge. The existing vfio framework allows the portdrv driver to
be bound to the bridge while its downstream devices are assigned to user
space.
When an iommu group has DMA_OWNER_PRIVATE_DOMAIN_USER set for the first
time, it is a contract that the group could be assigned to userspace from
now on. The group must be detached from the default iommu domain and all
devices in this group are blocked from doing DMA until it is attached to a
user
The pci_dma_configure() marks the iommu_group as containing only devices
with kernel drivers that manage DMA. Avoid this default behavior for the
pci_stub because it does not program any DMA itself. This allows the
pci_stub still able to be used by the admin to block driver binding after
applying
The original post and intent of this series is here.
https://lore.kernel.org/linux-iommu/2025020552.2378167-1-baolu...@linux.intel.com/
Change log:
v1: initial post
-
https://lore.kernel.org/linux-iommu/2025020552.2378167-1-baolu...@linux.intel.com/
v2:
- Move kernel dma ownership
On Sat, Nov 27, 2021 at 02:21:17AM +0100, Thomas Gleixner wrote:
> This is the second part of [PCI]MSI refactoring which aims to provide the
> ability of expanding MSI-X vectors after enabling MSI-X.
>
> The first part of this work can be found here:
>
>
From: Jason Gunthorpe
commit 60720a0fc646 ("vfio: Add device tracking during unbind") added the
unbound list to plug a problem with KVM where KVM_DEV_VFIO_GROUP_DEL
relied on vfio_group_get_external_user() succeeding to return the
vfio_group from a group file descriptor. The unbound list allowed
The iommu group changes notifer is not referenced in the tree. Remove it
to avoid dead code.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 23 -
drivers/iommu/iommu.c | 75 ---
2 files changed, 98
The iommu core and driver core have been enhanced to avoid unsafe driver
binding to a live group after iommu_group_set_dma_owner(PRIVATE_USER)
has been called. There's no need to register iommu group notifier. This
removes the iommu group notifer which contains BUG_ON() and WARN().
Signed-off-by:
From: Jason Gunthorpe
Tegra joins many platform devices onto the same iommu_domain and builds
sort-of a DMA API on top of it.
Given that iommu_attach/detatch_device_shared() has supported this usage
model. Each device that wants to use the special domain will use
suppress_auto_claim_dma_owner
The iommu_attach/detach_device() interfaces were exposed for the device
drivers to attach/detach their own domains. The commit <426a273834eae>
("iommu: Limit iommu_attach/detach_device to device with their own group")
restricted them to singleton groups to avoid different device in a group
Set DMA_OWNER_PRIVATE_DOMAIN_USER when an iommu group is set to a
container, and release DMA_OWNER_USER once the iommu group is unset
from a container.
Signed-off-by: Lu Baolu
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 +
drivers/vfio/pci/vfio_pci.c | 1 +
As DMA USER ownership is claimed for the iommu group when a vfio group is
added to a vfio container, the vfio group viability is guaranteed as long
as group->container_users > 0. Remove those unnecessary group viability
checks which are only hit when group->container_users is not zero.
The only
On 10.11.21 09:50, Yong Wu wrote:
On Wed, 2021-11-10 at 07:29 +0200, Dafna Hirschfeld wrote:
On 10.11.21 04:20, Yong Wu wrote:
On Tue, 2021-11-09 at 14:21 +0200, Dafna Hirschfeld wrote:
Hi
This patch is needed in order to update the tlb when a device is
powered on.
Could you send this
On Sat, Nov 27, 2021 at 02:20:13AM +0100, Thomas Gleixner wrote:
> Remove the register lock from struct device and use the one in
> struct msi_device_data.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/base/core.c|1 -
> drivers/pci/msi/msi.c |2 +-
> include/linux/device.h |
On Sat, Nov 27, 2021 at 02:20:08AM +0100, Thomas Gleixner wrote:
> The only unconditional part of MSI data in struct device is the irqdomain
> pointer. Everything else can be allocated on demand. Create a data
> structure and move the irqdomain pointer into it. The other MSI specific
> parts are
On Sat, Nov 27, 2021 at 02:20:09AM +0100, Thomas Gleixner wrote:
> Create struct msi_device_data and add a pointer of that type to struct
> dev_msi_info, which is part of struct device. Provide an allocator function
> which can be invoked from the MSI interrupt allocation code pathes.
>
>
On Sat, Nov 27, 2021 at 02:20:06AM +0100, Thomas Gleixner wrote:
> This is the second part of [PCI]MSI refactoring which aims to provide the
> ability of expanding MSI-X vectors after enabling MSI-X.
>
> The first part of this work can be found here:
>
>
32 matches
Mail list logo
