Hi,
On 1/8/20 3:16 AM, Barret Rhoden via iommu wrote:
The VT-d docs specify requirements for the RMRR entries base and end
(called 'Limit' in the docs) addresses.
This commit will cause the DMAR processing to skip any RMRR entries that
do not meet these requirements and mark the firmware as
On Tue, 7 Jan 2020, Christoph Hellwig wrote:
> > On 01/01/2020 1:54 am, David Rientjes via iommu wrote:
> >> Christoph, Thomas, is something like this (without the diagnosic
> >> information included in this patch) acceptable for these allocations?
> >> Adding expansion support when the pool is
RMRR entries describe memory regions that are DMA targets for devices
outside the kernel's control.
RMRR entries that fail the sanity check are pointing to regions of
memory that the firmware did not tell the kernel are reserved or
otherwise should not be used.
Instead of aborting DMAR
The VT-d docs specify requirements for the RMRR entries base and end
(called 'Limit' in the docs) addresses.
This commit will cause the DMAR processing to skip any RMRR entries that
do not meet these requirements and mark the firmware as tainted, since
the firmware is giving us junk.
Commit f036c7fa0ab6 ("iommu/vt-d: Check VT-d RMRR region in BIOS is
reported as reserved") caused a machine to fail to boot for me, but only
after a kexec.
Buggy firmware provided an RMRR entry with base and end both == 0. That
is an invalid RMRR format, and only happens to pass the RMRR sanity
On Tue, Jan 07, 2020 at 06:18:28PM +, Robin Murphy wrote:
> On 07/01/2020 5:38 pm, Naresh Kamboju wrote:
> > Following build error on stable-rc 5.4.9-rc1 for arm architecture.
> >
> > dma/direct.c: In function 'dma_direct_possible':
> > dma/direct.c:329:3: error: too many arguments to
On 07/01/2020 5:38 pm, Naresh Kamboju wrote:
Following build error on stable-rc 5.4.9-rc1 for arm architecture.
dma/direct.c: In function 'dma_direct_possible':
dma/direct.c:329:3: error: too many arguments to function 'dma_capable'
dma_capable(dev, dma_addr, size, true);
^~~
Following build error on stable-rc 5.4.9-rc1 for arm architecture.
dma/direct.c: In function 'dma_direct_possible':
dma/direct.c:329:3: error: too many arguments to function 'dma_capable'
dma_capable(dev, dma_addr, size, true);
^~~
In file included from
On Mon, Jan 06, 2020 at 10:27:27AM -0500, Qian Cai wrote:
> The commit c18647900ec8 ("iommu/dma: Relax locking in
> iommu_dma_prepare_msi()") introduced a compliation warning,
>
> drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi':
> drivers/iommu/dma-iommu.c:1206:27: warning:
On Tue, Jan 07, 2020 at 09:00:14AM -0500, Brian Masney wrote:
> On Tue, Jan 07, 2020 at 02:25:30PM +0100, Joerg Roedel wrote:
> > On Tue, Dec 31, 2019 at 10:39:49PM -0500, Brian Masney wrote:
> > > drivers/iommu/qcom_iommu.c | 12 ++--
> > > 1 file changed, 10 insertions(+), 2
On Tue, Jan 07, 2020 at 02:25:30PM +0100, Joerg Roedel wrote:
> On Tue, Dec 31, 2019 at 10:39:49PM -0500, Brian Masney wrote:
> > drivers/iommu/qcom_iommu.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
>
> Shortened commit-message a bit and applied for v5.5, thanks.
On Tue, Dec 31, 2019 at 01:24:18PM -0700, Jon Derrick wrote:
> Jon Derrick (5):
> iommu: Remove device link to group on failure
> iommu/vt-d: Unlink device if failed to add to group
Added 'Fixes:' tags to these two and applied them for v5.5, thanks.
WTF is a NVMe host supposed to mean for a PCIe device. NVMe defines
the host as following:
"1.6.16 host
An entity that interfaces to an NVM subsystem through one or more
controllers and submits commands to Submission Queues and retrieves
command completions from Completion Queues."
in other
On Tue, Dec 31, 2019 at 10:39:49PM -0500, Brian Masney wrote:
> drivers/iommu/qcom_iommu.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
Shortened commit-message a bit and applied for v5.5, thanks.
___
iommu mailing list
On Mon, Dec 30, 2019 at 01:56:54PM +0800, Adrian Huang wrote:
> From: Adrian Huang
>
> The bit 13 and bit 14 of the IOMMU control register are
> PPRLogEn and PPRIntEn. They are related to PPR (Peripheral Page
> Request) instead of 'PPF'. Fix them accrodingly.
>
> Signed-off-by: Adrian Huang
>
On Tue, Dec 24, 2019 at 10:46:47PM +0800, Adrian Huang wrote:
> From: Adrian Huang
>
> The usage of the local variables 'range' and 'misc' was removed
> from commit 226e889b20a9 ("iommu/amd: Remove first/last_device handling")
> and commit 23c742db2171 ("iommu/amd: Split out PCI related parts of
On Thu, Jan 02, 2020 at 08:18:01AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> Below patches have been piled up for v5.6.
>
> - Some preparation patches for VT-d nested mode support
>- VT-d Native Shared virtual memory cleanup and fixes
>- Use 1st-level for IOVA translation
>
> - VT-d
On Fri, Dec 27, 2019 at 12:56:18AM +0100, Patrick Steinhardt wrote:
>
> I've recently spotted above warning in v5.5-rc3. The attached fix
> is rather intended as a discussion starter -- it's quite likely
> to be wrong as I ain't got much of a clue about the IOMMU
> subsystem.
>
>
On Mon, Jan 06, 2020 at 01:26:58PM +, Robin Murphy wrote:
> On 04/01/2020 12:20 am, Brian Masney wrote:
> > When attempting to load the qcom-iommu driver, and an -EPROBE_DEFER
> > error occurs, the following attempted NULL pointer deference occurs:
> >
> > Unable to handle kernel NULL
On Mon, 2020-01-06 at 15:57 -0600, Rob Herring wrote:
> On Sun, 5 Jan 2020 18:45:05 +0800, Chao Hao wrote:
> > This patch adds description for MT6779 IOMMU.
> >
> > MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which
> > use ARM Short-Descriptor translation format.
> >
> > The MT6779
On Mon, Jan 06, 2020 at 05:34:00PM +, Robin Murphy wrote:
> On 01/01/2020 1:54 am, David Rientjes via iommu wrote:
>> Christoph, Thomas, is something like this (without the diagnosic
>> information included in this patch) acceptable for these allocations?
>> Adding expansion support when the
21 matches
Mail list logo
