On 26.08.2021 15:16, Andrew Cooper wrote: > On 26/08/2021 08:24, Jan Beulich wrote: >> 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 gets failed in this case instead. >> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> Reviewed-by: Paul Durrant <p...@xen.org> > > I'm not certain this is correct in combination with memory encryption.
Which we don't enable. I don't follow why you put this up as an extra requirement. I'm adding checks based on IOMMU-specific data alone. I think that's a fair and consistent step in the right direction, no matter that there may be another step to go. Plus ... > The upper bits are the KeyID, but we shouldn't find any of those set in > an IVMD range. I think at a minimum, we need to reduce the address > check by the stolen bits for encryption, which gives a lower bound. ... aren't you asking here to consume data I'm only making available in the still pending "x86/AMD: make HT range dynamic for Fam17 and up", where I (now, i.e. v2) adjust paddr_bits accordingly? Else I'm afraid I don't even know what you're talking about. Jan
