similar to: [PATCH 00/14] iommu: Move iommu_fwspec out of 'struct device'

Hi, here is a patch-set to rename iommu_param to dev_iommu and establish it as a struct for generic per-device iommu-data. Also move the iommu_fwspec pointer from struct device into dev_iommu to have less iommu-related pointers in struct device. The bigger part of this patch-set moves the iommu_priv pointer from struct iommu_fwspec to dev_iommu, making is usable for iommu-drivers which do not

On Fri, Mar 06, 2020 at 04:39:37PM +0800, Hanjun Guo wrote: > Hi Joerg, > > On 2020/2/28 23:08, Joerg Roedel wrote: > > Hi, > > > > here is a patch-set to rename iommu_param to dev_iommu and > > establish it as a struct for generic per-device iommu-data. > > Also move the iommu_fwspec pointer from struct device into > > dev_iommu to have less

Hi Jean, On 11/15/18 5:52 PM, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into > corresponding

Hi Jean, On 11/15/18 5:52 PM, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into > corresponding

When the device offers the probe feature, send a probe request for each device managed by the IOMMU. Extract RESV_MEM information. When we encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell other subsystems that there is no need to map the MSI doorbell in the virtio-iommu, because MSIs bypass it. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at

Hi Jean-Philippe, On 17/11/17 19:52, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will tell other subsystems that there is no need to map the MSI > doorbell in the virtio-iommu,

When the device offers the probe feature, send a probe request for each device managed by the IOMMU. Extract RESV_MEM information. When we encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell other subsystems that there is no need to map the MSI doorbell in the virtio-iommu, because MSIs bypass it. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at

On 14/02/18 14:53, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will tell other subsystems that there is no need to map the MSI > doorbell in the virtio-iommu, because MSIs

Hi Jean-Philippe, On 17/11/17 19:52, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will tell other subsystems that there is no need to map the MSI > doorbell in the virtio-iommu,

Hi Jean-Philippe, On 17/11/17 19:52, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will tell other subsystems that there is no need to map the MSI > doorbell in the virtio-iommu,

From: Joerg Roedel <jroedel at suse.de> Convert the arm-smmu and arm-smmu-v3 drivers to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- drivers/iommu/arm-smmu-v3.c | 38 ++++++++++-------------------------- drivers/iommu/arm-smmu.c | 39

On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote: > From: Will Deacon <will.deacon at arm.com> > > Booting Linux on an ARM fastmodel containing an SMMU emulation results > in an unexpected I/O page fault from the legacy virtio-blk PCI device: > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: > [ 1.211800] arm-smmu-v3 2b400000.smmu:

On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote: > From: Will Deacon <will.deacon at arm.com> > > Booting Linux on an ARM fastmodel containing an SMMU emulation results > in an unexpected I/O page fault from the legacy virtio-blk PCI device: > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: > [ 1.211800] arm-smmu-v3 2b400000.smmu:

On Wed, Jan 11, 2017 at 2:01 AM, Will Deacon <will.deacon at arm.com> wrote: > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: >> On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote: >> > From: Will Deacon <will.deacon at arm.com> >> > >> > Booting Linux on an ARM fastmodel containing an SMMU emulation results >>

On Wed, Jan 11, 2017 at 2:01 AM, Will Deacon <will.deacon at arm.com> wrote: > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: >> On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote: >> > From: Will Deacon <will.deacon at arm.com> >> > >> > Booting Linux on an ARM fastmodel containing an SMMU emulation results >>

On 20/01/17 10:33, Will Deacon wrote: > On Thu, Jan 19, 2017 at 11:51:06PM +0200, Michael S. Tsirkin wrote: >> On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: >>> On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: >>>> On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: >>>>> On Mon, Jan 16, 2017 at 04:18:03PM

On 20/01/17 10:33, Will Deacon wrote: > On Thu, Jan 19, 2017 at 11:51:06PM +0200, Michael S. Tsirkin wrote: >> On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: >>> On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: >>>> On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: >>>>> On Mon, Jan 16, 2017 at 04:18:03PM

On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote: > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote: > > > From: Will Deacon <will.deacon at arm.com> > > > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results > > > in an

On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote: > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote: > > > From: Will Deacon <will.deacon at arm.com> > > > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results > > > in an

From: Thierry Reding <treding at nvidia.com> This dummy implementation is useful to avoid a dependency on the IOMMU_API Kconfig symbol in drivers that can optionally use the IOMMU API. In order to fully use this, also move the struct iommu_fwspec definition out of the IOMMU_API protected region. Suggested-by: Ben Dooks <ben.dooks at codethink.co.uk> Signed-off-by: Thierry Reding