> +/* is_downstream_to_pci_bridge - test if a device belongs to the
> + * PCI sub-hierarchy of a candidate PCI-PCI bridge
> + *
> + * @dev: candidate PCI device belonging to @bridge PCI sub-hierarchy
> + * @bridge: the candidate PCI-PCI bridge
> + *
> + * Return: true if @dev belongs to @bridge PCI
> } else if ((start >= a) && (end <= b)) {
> if (new->type == type)
> - goto done;
> + return 0;
> else
> pos = pos->next;
Please remove the pointless els
On Sat, May 25, 2019 at 01:41:31PM +0800, Lu Baolu wrote:
> Some platforms may support ACPI name-space enumerated devices
> that are capable of generating DMA requests. Platforms which
> support DMA remapping explicitly declares any such DMA-capable
> ACPI name-space devices in the platform through
On Thu, May 23, 2019 at 10:46 PM Frederic Chen
wrote:
>
> Dear Tomasz,
>
> Thank you for your comments.
>
>
> On Wed, 2019-05-22 at 19:25 +0900, Tomasz Figa wrote:
> > Hi Frederic,
> >
> > On Wed, May 22, 2019 at 03:14:15AM +0800, Frederic Chen wrote:
> > > Dear Tomasz,
> > >
> > > I appreciate yo
Hi,
On 5/28/19 7:50 PM, Eric Auger wrote:
Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory
region type, let's report USB and GFX RMRRs as relaxable ones.
We introduce a new device_rmrr_is_relaxable() helper to check
whether the rmrr belongs to the relaxable category.
This allows t
Hi,
On 5/28/19 7:50 PM, Eric Auger wrote:
Several call sites are about to check whether a device belongs
to the PCI sub-hierarchy of a candidate PCI-PCI bridge.
Introduce an helper to perform that check.
This looks good to me.
Reviewed-by: Lu Baolu
Best regards,
Baolu
Signed-off-by: Eri
Hi,
On 5/28/19 7:50 PM, Eric Auger wrote:
In the case the RMRR device scope is a PCI-PCI bridge, let's check
the device belongs to the PCI sub-hierarchy.
This looks good to me.
Reviewed-by: Lu Baolu
Best regards,
Baolu
Fixes: 0659b8dc45a6 ("iommu/vt-d: Implement reserved region get/put
Hi,
On 5/28/19 7:50 PM, Eric Auger wrote:
When reading the vtd specification and especially the
Reserved Memory Region Reporting Structure chapter,
it is not obvious a device scope element cannot be a
PCI-PCI bridge, in which case all downstream ports are
likely to access the reserved memory reg
Hi Eric,
On 5/28/19 7:50 PM, Eric Auger wrote:
intel_iommu_get_resv_regions() aims to return the list of
reserved regions accessible by a given @device. However several
devices can access the same reserved memory region and when
building the list it is not safe to use a single iommu_resv_region
On Thu, 23 May 2019 18:24:33 +0200
Cornelia Huck wrote:
> On Thu, 23 May 2019 14:25:25 +0200
> Pierre Morel wrote:
>
> > We define a new device region in vfio.h to be able to
> > get the ZPCI CLP information by reading this region from
> > userland.
> >
> > We create a new file, vfio_zdev.h to
On Tue, 28 May 2019 15:43:42 -0600
Alex Williamson wrote:
> On Thu, 23 May 2019 14:25:25 +0200
> Pierre Morel wrote:
>
> > We define a new device region in vfio.h to be able to
> > get the ZPCI CLP information by reading this region from
> > userland.
> >
> > We create a new file, vfio_zdev.h
On Thu, 23 May 2019 14:25:25 +0200
Pierre Morel wrote:
> We define a new device region in vfio.h to be able to
> get the ZPCI CLP information by reading this region from
> userland.
>
> We create a new file, vfio_zdev.h to define the structure
> of the new region we defined in vfio.h
>
> Signed
On Thu, 23 May 2019 14:25:26 +0200
Pierre Morel wrote:
> We define a new configuration entry for VFIO/PCI, VFIO_PCI_ZDEV
>
> When the VFIO_PCI_ZDEV feature is configured we initialize
> a new device region, VFIO_REGION_SUBTYPE_ZDEV_CLP, to hold
> the information from the ZPCI device the userland
There are a few macros in DMA have single-char identifiers make the code
hard to read. Replace them with meaningful names.
Signed-off-by: Qian Cai
---
include/linux/dma-mapping.h | 24
include/linux/dmar.h| 14 --
2 files changed, 24 insertions(+), 14
When amd_iommu=off was specified on the command line, free_X_resources
functions were called immediately after early_amd_iommu_init. They were
then called again when amd_iommu_init also failed (as expected).
Instead, call them only once: at the end of state_next() whenever
there's an error. These
This series makes error handling more robust in the amd_iommu init
code. It was initially motivated by problematic firmware that does not
set up the physical address of the iommu. This led to a NULL dereference
panic when iommu_disable was called during cleanup.
While the first patch is sufficient
The fallback to the GART driver in the case amd_iommu doesn't work was
executed in a function called free_iommu_resources, which didn't really
make sense. This was even being called twice if amd_iommu=off was
specified on the command line.
The only complication is that it needs to be verified that
Make it safe to call iommu_disable during early init error conditions
before mmio_base is set, but after the struct amd_iommu has been added
to the amd_iommu_list. For example, this happens if firmware fails to
fill in mmio_phys in the ACPI table leading to a NULL pointer
dereference in iommu_featu
On Tue, May 14, 2019 at 10:55:46AM -0400, Qian Cai wrote:
> Jroedel, I am wondering what the plan for 41e59a41fc5d1 (iommu tree) or this
> patch to be pushed to the linux-next or mainline...
Looks like I applied that patch directly to the master branch, which is
not what goes upstream. I cherry-pi
On 2019/5/27 22:21, Joerg Roedel wrote:
> Hi Zhen Lei,
>
> On Mon, May 20, 2019 at 09:59:47PM +0800, Zhen Lei wrote:
>> arch/ia64/kernel/pci-dma.c| 2 +-
>> arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
>> arch/s390/pci/pci_dma.c | 2 +-
>> arch/x86/ke
Hi Joerg,
On 5/27/19 5:23 PM, Joerg Roedel wrote:
> On Mon, May 27, 2019 at 10:55:36AM +0200, Eric Auger wrote:
>> -list_add_tail(&rmrr->resv->list, head);
>> +length = rmrr->end_address - rmrr->base_address + 1;
>> +resv = iommu_alloc_re
When reading the vtd specification and especially the
Reserved Memory Region Reporting Structure chapter,
it is not obvious a device scope element cannot be a
PCI-PCI bridge, in which case all downstream ports are
likely to access the reserved memory region. Let's handle
this case in device_has_rmr
Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory
region type, let's report USB and GFX RMRRs as relaxable ones.
We introduce a new device_rmrr_is_relaxable() helper to check
whether the rmrr belongs to the relaxable category.
This allows to have a finer reporting at IOMMU API level o
Several call sites are about to check whether a device belongs
to the PCI sub-hierarchy of a candidate PCI-PCI bridge.
Introduce an helper to perform that check.
Signed-off-by: Eric Auger
---
drivers/iommu/intel-iommu.c | 37 +
1 file changed, 29 insertions(+)
Introduce a new type for reserved region. This corresponds
to directly mapped regions which are known to be relaxable
in some specific conditions, such as device assignment use
case. Well known examples are those used by USB controllers
providing PS/2 keyboard emulation for pre-boot BIOS and
early
In the case the RMRR device scope is a PCI-PCI bridge, let's check
the device belongs to the PCI sub-hierarchy.
Fixes: 0659b8dc45a6 ("iommu/vt-d: Implement reserved region get/put callbacks")
Signed-off-by: Eric Auger
---
drivers/iommu/intel-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 d
intel_iommu_get_resv_regions() aims to return the list of
reserved regions accessible by a given @device. However several
devices can access the same reserved memory region and when
building the list it is not safe to use a single iommu_resv_region
object, whose container is the RMRR. This iommu_re
In case we expand an existing region, we unlink
this latter and insert the larger one. In
that case we should free the original region after
the insertion. Also we can immediately return.
Fixes: 6c65fb318e8b ("iommu: iommu_get_group_resv_regions")
Signed-off-by: Eric Auger
---
drivers/iommu/iom
Currently the Intel reserved region is attached to the
RMRR unit and when building the list of RMRR seen by a device
we link this unique reserved region without taking care of
potential multiple usage of this reserved region by several devices.
Also while reading the vtd spec it is unclear to me w
On 27/05/2019 16:15, Michael S. Tsirkin wrote:
> On Mon, May 27, 2019 at 11:26:04AM +0200, Joerg Roedel wrote:
>> On Sun, May 12, 2019 at 12:31:59PM -0400, Michael S. Tsirkin wrote:
>>> OK this has been in next for a while.
>>>
>>> Last time IOMMU maintainers objected. Are objections
>>> still in f
30 matches
Mail list logo
