amd-vi: fix IVMD memory type checks

The current code that parses the IVMD blocks is relaxed with regard to the
restriction that such unity regions should always fall into memory ranges
marked as reserved in the memory map.

However the type checks for the IVMD addresses are inverted, and as a result
IVMD ranges falling into RAM areas are accepted.  Note that having such ranges
in the first place is a firmware bug, as IVMD should always fall into reserved
ranges.

Fixes: ed6c77ebf0 ('AMD/IOMMU: check / convert IVMD ranges for being / to be reserved')
Reported-by: Ox <oxjo@proton.me>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Tested-by: oxjo <oxjo@proton.me>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This commit is contained in:
Roger Pau Monné authored and Jan Beulich committed 2024-02-06 11:56:13 +01:00
1 parent 8ac8999d70
commit 83afa31358
1 file changed
+8 -3
+8 -3
View File
@@ -426,9 +426,14 @@ static int __init parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block)
return -EIO;
}
/* Types which won't be handed out are considered good enough. */
if ( !(type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI |
RAM_TYPE_UNUSABLE)) )
/*
* Types which aren't RAM are considered good enough.
* Note that a page being partially RESERVED, ACPI or UNUSABLE will
* force Xen into assuming the whole page as having that type in
* practice.
*/
if ( type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI |
RAM_TYPE_UNUSABLE) )
continue;
AMD_IOMMU_ERROR("IVMD: page at %lx can't be converted\n", addr);
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.