[PATCH v7 5/8] AMD/IOMMU: also insert IVMD ranges into Dom0's page tables

2021-08-26 Thread Jan Beulich
So far only one region would be taken care of, if it can be placed in the exclusion range registers of the IOMMU. Take care of further ranges as well. Seeing that we've been doing fine without this, make both insertion and removal best effort only. Signed-off-by: Jan Beulich Reviewed-by: Paul Dur

RE: [XEN RFC PATCH 26/40] xen/arm: Add boot and secondary CPU to NUMA system

2021-08-26 Thread Wei Chen
Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2021年8月26日 0:58 > To: Wei Chen ; xen-devel@lists.xenproject.org; > sstabell...@kernel.org; jbeul...@suse.com > Cc: Bertrand Marquis > Subject: Re: [XEN RFC PATCH 26/40] xen/arm: Add boot and secondary CPU to > NUMA system > >

[PATCH v7 4/8] AMD/IOMMU: check IVMD ranges against host implementation limits

2021-08-26 Thread Jan Beulich
When such ranges can't be represented as 1:1 mappings in page tables, reject them as presumably bogus. Note that when we detect features late (because of EFRSup being clear in the ACPI tables), it would be quite a bit of work to check for (and drop) out of range IVMD ranges, so IOMMU initialization

[PATCH v7 3/8] AMD/IOMMU: improve (extended) feature detection

2021-08-26 Thread Jan Beulich
First of all the documentation is very clear about ACPI table data superseding raw register data. Use raw register data only if EFRSup is clear in the ACPI tables (which may still go too far). Additionally if this flag is clear, the IVRS type 11H table is reserved and hence may not be recognized.

[PATCH v7 2/8] AMD/IOMMU: obtain IVHD type to use earlier

2021-08-26 Thread Jan Beulich
Doing this in amd_iommu_prepare() is too late for it, in particular, to be used in amd_iommu_detect_one_acpi(), as a subsequent change will want to do. Moving it immediately ahead of amd_iommu_detect_acpi() is (luckily) pretty simple, (pretty importantly) without breaking amd_iommu_prepare()'s logi

[PATCH v7 1/8] AMD/IOMMU: check / convert IVMD ranges for being / to be reserved

2021-08-26 Thread Jan Beulich
While the specification doesn't say so, just like for VT-d's RMRRs no good can come from these ranges being e.g. conventional RAM or entirely unmarked and hence usable for placing e.g. PCI device BARs. Check whether they are, and put in some limited effort to convert to reserved. (More advanced log

[PATCH v7] AMD/IOMMU: further work split from XSA-378

2021-08-26 Thread Jan Beulich
Along the pieces that were determined to have security relevance there are quite a few more fixes / improvements (or so I hope) which were decided to not become part of the XSA itself. Hence also why this is v7 and why several of them already have a Reviewed-by tag. Here we go. 1: check / convert

RE: [XEN RFC PATCH 24/40] xen/arm: introduce a helper to parse device tree NUMA distance map

2021-08-26 Thread Wei Chen
Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2021年8月25日 21:56 > To: Wei Chen ; xen-devel@lists.xenproject.org; > sstabell...@kernel.org > Cc: Bertrand Marquis ; Jan Beulich > > Subject: Re: [XEN RFC PATCH 24/40] xen/arm: introduce a helper to parse > device tree NUMA dist

<    1   2