On 3/9/20 12:01 PM, Hans de Goede wrote:
Hi,
On 3/9/20 4:57 PM, Barret Rhoden wrote:
On 3/9/20 10:01 AM, Hans de Goede wrote:
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* signifi
On 3/9/20 10:01 AM, Hans de Goede wrote:
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant kernel issues that need prompt attention if they should ever
* appear at runtime.
On 1/7/20 8:27 PM, Lu Baolu wrote:
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a8bb458845bc..32c3c6338a3d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4315,13 +4315,25 @@ static void __init init_iommu_pm_ops(void)
static inline
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 processing
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.
Signed-off-b
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
c
On 12/17/19 2:19 PM, Chen, Yian wrote:
Regardless, I have two other patches in this series that could resolve
the problem for me and probably other people. I'd just like at least
one of the three patches to get merged so that my machine boots when
the original commit f036c7fa0ab6 ("iommu/vt-d:
On 12/16/19 2:07 PM, Chen, Yian wrote:
On 12/11/2019 11:46 AM, Barret Rhoden wrote:
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
On 12/11/19 9:43 PM, Lu Baolu wrote:
The VT-d spec defines the BIOS considerations about RMRR in section 8.4:
"
BIOS must report the RMRR reported memory addresses as reserved (or as
EFI runtime) in the system memory map returned through methods such as
INT15, EFI GetMemoryMap etc.
"
So we shou
Hi -
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.
Firmware provided an RMRR entry with base and end both == 0:
DMAR: RMRR base: 0x00 end: 0x00
Yes, firm
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 with the expectation that firmware
is giving us junk.
Signed-off-by: Barret Rhoden
The RMRR sanity check is to confirm that the memory pointed to by the
RMRR entry is not used by the kernel. e820 RESERVED memory will not be
used. However, there are ranges of physical memory that are not covered
by the e820 table at all. The kernel will not use this memory, either.
This commit
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 processing
13 matches
Mail list logo
