Hi Eric,
On 5/16/19 6:08 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.
This allows to have a finer reporting at IOMMU API level of
reserved memory regions. This will be exploitable by VFIO to
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
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
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
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
On Thu, 16 May 2019 16:57:42 +0200
Christian Borntraeger wrote:
> Alex,
>
> patch 1 and 3 are s390 specific, 2 and 4 are vfio common code.
> Are you ok with the common code changes? If yes, would you prefer to have this
> via the s390 tree (Martin) or your tree?
Hi Christian,
The vfio code
On Fri, 10 May 2019 10:22:33 +0200
Pierre Morel wrote:
> To use the VFIO_IOMMU_GET_INFO to retrieve IOMMU specific information,
> we define a new flag VFIO_IOMMU_INFO_CAPABILITIES in the
> vfio_iommu_type1_info structure and the associated capability
> information block.
>
> Signed-off-by:
On 16/05/2019 14:23, Auger Eric wrote:
Hi Robin,
On 5/16/19 2:46 PM, Robin Murphy wrote:
On 16/05/2019 11:08, Eric Auger wrote:
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
On 16/05/2019 18:06, Alex Williamson wrote:
On Thu, 16 May 2019 14:58:08 +0200
Auger Eric wrote:
Hi Jean-Philippe,
On 5/16/19 2:43 PM, Jean-Philippe Brucker wrote:
On 16/05/2019 12:45, Auger Eric wrote:
Hi Jean-Philippe,
On 5/16/19 1:16 PM, Jean-Philippe Brucker wrote:
On 16/05/2019
On Thu, 16 May 2019 14:58:08 +0200
Auger Eric wrote:
> Hi Jean-Philippe,
>
> On 5/16/19 2:43 PM, Jean-Philippe Brucker wrote:
> > On 16/05/2019 12:45, Auger Eric wrote:
> >> Hi Jean-Philippe,
> >>
> >> On 5/16/19 1:16 PM, Jean-Philippe Brucker wrote:
> >>> On 16/05/2019 11:08, Eric Auger
On Thu, 16 May 2019 15:23:17 +0200
Auger Eric wrote:
> Hi Robin,
> On 5/16/19 2:46 PM, Robin Murphy wrote:
> >> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >> index ba91666998fb..14a521f85f14 100644
> >> --- a/include/linux/iommu.h
> >> +++ b/include/linux/iommu.h
> >> @@ -135,6
On Thu, 16 May 2019 15:14:40 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> On 03/05/2019 23:32, Jacob Pan wrote:
> > +/**
> > + * struct gpasid_bind_data - Information about device and guest
> > PASID binding
> > + * @gcr3: Guest CR3 value from guest mm
> > + * @pasid: Process address
Alex,
patch 1 and 3 are s390 specific, 2 and 4 are vfio common code.
Are you ok with the common code changes? If yes, would you prefer to have this
via the s390 tree (Martin) or your tree?
On 10.05.19 10:22, Pierre Morel wrote:
> To use the VFIO_IOMMU_GET_INFO to retrieve IOMMU specific
Hi Jacob,
On 03/05/2019 23:32, Jacob Pan wrote:
> +/**
> + * struct gpasid_bind_data - Information about device and guest PASID binding
> + * @gcr3:Guest CR3 value from guest mm
> + * @pasid: Process address space ID used for the guest mm
> + * @addr_width: Guest address width. Paging
Dne 16.5.2019 v 15:11 Oliver Neukum napsal(a):
You will be asked whether this worked in earlier version of the
kernel. The answer would be: yes, no, unknown (why)
HTH
Oliver
Thank you, I sent new report.
starosta
___
iommu
On Do, 2019-05-16 at 14:29 +0200, starost...@gmail.com wrote:
> Dne 16.5.2019 v 10:34 Oliver Neukum napsal(a):
> > Mention
> >
> > 1. kernel version
> > 2. whether this is known to be a regression
>
> Sorry for question, can you more specify what you mean?
You will be asked whether this
Hi Robin,
On 5/16/19 2:46 PM, Robin Murphy wrote:
> On 16/05/2019 11:08, Eric Auger wrote:
>> 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
Hi Jean-Philippe,
On 5/16/19 2:43 PM, Jean-Philippe Brucker wrote:
> On 16/05/2019 12:45, Auger Eric wrote:
>> Hi Jean-Philippe,
>>
>> On 5/16/19 1:16 PM, Jean-Philippe Brucker wrote:
>>> On 16/05/2019 11:08, Eric Auger wrote:
Note: At the moment the sysfs ABI is not changed. However I
On 16/05/2019 11:08, Eric Auger wrote:
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
On 16/05/2019 12:45, Auger Eric wrote:
> Hi Jean-Philippe,
>
> On 5/16/19 1:16 PM, Jean-Philippe Brucker wrote:
>> On 16/05/2019 11:08, Eric Auger wrote:
>>> Note: At the moment the sysfs ABI is not changed. However I wonder
>>> whether it wouldn't be preferable to report the direct region as
>>>
Dne 16.5.2019 v 10:34 Oliver Neukum napsal(a):
Mention
1. kernel version
2. whether this is known to be a regression
Sorry for question, can you more specify what you mean?
3. include the log with iommu disabled and mention that you disabled
the IOMMU
4. Include the output of lsusb
Hi Jean-Philippe,
On 5/16/19 1:16 PM, Jean-Philippe Brucker wrote:
> On 16/05/2019 11:08, Eric Auger wrote:
>> Note: At the moment the sysfs ABI is not changed. However I wonder
>> whether it wouldn't be preferable to report the direct region as
>> "direct_relaxed" there. At the moment, in case
On 16/05/2019 11:08, Eric Auger wrote:
> Note: At the moment the sysfs ABI is not changed. However I wonder
> whether it wouldn't be preferable to report the direct region as
> "direct_relaxed" there. At the moment, in case the same direct
> region is used by 2 devices, one USB/GFX and another not
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
Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory
region type, let's report USB and GFX RMRRs as relaxable ones.
This allows to have a finer reporting at IOMMU API level of
reserved memory regions. This will be exploitable by VFIO to
define the usable IOVA range and detect potential
We plan to call iommu_alloc_resv_region in a non preemptible section.
Pass a GFP flag to the function and update all the call sites.
Signed-off-by: Eric Auger
---
drivers/acpi/arm64/iort.c | 3 ++-
drivers/iommu/amd_iommu.c | 7 ---
drivers/iommu/arm-smmu-v3.c | 2 +-
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
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
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
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
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
Hi
On 5/16/19 10:47 AM, Eric Auger wrote:
> 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
>
Few Qualcomm platforms such as, sdm845 have an additional outer
cache called as System cache, aka. Last level cache (LLC) that
allows non-coherent devices to upgrade to using caching.
This cache sits right before the DDR, and is tightly coupled
with the memory controller. The clients using this
Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory
region type, let's report USB and GFX RMRRs as relaxable ones.
This allows to have a finer reporting at IOMMU API level of
reserved memory regions. This will be exploitable by VFIO to
define the usable IOVA range and detect potential
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
On Do, 2019-05-16 at 10:20 +0200, starost...@gmail.com wrote:
> Dne 16.5.2019 v 9:58 Oliver Neukum napsal(a):
> > > > 2.Send a new report to the corresponding mailing list
> > >
> > > Which mailing list is correct?
> >
> > In that case linux-...@vger.kernel.org
> >
> > HTH
> >
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
We plan to call iommu_alloc_resv_region in a non preemptible section.
Pass a GFP flag to the function and update all the call sites.
Signed-off-by: Eric Auger
---
drivers/acpi/arm64/iort.c | 3 ++-
drivers/iommu/amd_iommu.c | 7 ---
drivers/iommu/arm-smmu-v3.c | 2 +-
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
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
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
Dne 16.5.2019 v 9:58 Oliver Neukum napsal(a):
2.Send a new report to the corresponding mailing list
Which mailing list is correct?
In that case linux-...@vger.kernel.org
HTH
Oliver
Is there some rules how to send bug report? Or I can send report with
"my amateur
On Thu, May 16, 2019 at 5:03 AM Bjorn Andersson
wrote:
>
> Describe the memory related to page table walks as non-cachable for iommu
> instances that are not DMA coherent.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/iommu/io-pgtable-arm.c | 12 +---
> 1 file changed, 9
44 matches
Mail list logo
