[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 26 Aug 2021 14:31:28 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AuXEDa2CkHy4uOPC7f4nQ7UbOd9kfMmjP2WmCuCF9mM=; b=BjO5QJGOyHNZ9dpxtVqsXo+dnldaRL+HiwwFZmWLERm2AgIN4m61m8kL0pDKdkKoFrOxZ4xrrNXcOQJiMGNceQgBH0hanafogvVudzSgNGk12APb9uklf9nCDICRY14JnEl8jL4aUZakenYbsl72riIHv+PQ1lGpRugH2WEcORWrgKhzjdn24/HV+N2gdWoUfBd8VbN5E51XWzy2Vsbp/tRaDXsnsp+KHziELe6j7xhwT4yKhtHyv0Wj+INVyDoEAnAWEZuoVOipHxwE9sMOME01VKG8myt70uwLwFpYY2v44sU06vWRhQyXWBa1TIOXw7CQardpc1IiaZ5oITpfNA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A0j7YBaQozd0nkyh5DNIbzA6aUL1jQcrS/L2ON2wHXF78OYXxxYsm05vzMkBJbTvNnK45h0Nq/buWEeCAdvJIuHWwnBGkQOczQGGYyeB8WKs5omJg/LY6IxfEc73XUgvQzJRbRbJN4D6231+y32wpuyonTF2fFO7OKBUcRvtnwv3QIiONVdcB5LlR+QQv8/8LAUlUkMSRwpxJ4JVLZFQsHTNSXjB/RQQtWwrcluRBsJfdLQJpPXyu++zWLGu44T5EJv8ONepoSeZOpnWbFPdl7hcrY2/he1wZ56g05MRm6+XYmO+1okujkgehWfgRIcmx8DgBuT71q2Rm1s2UVZ2ig==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Thu, 26 Aug 2021 12:31:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.08.2021 14:10, Andrew Cooper wrote:
> On 26/08/2021 08:23, Jan Beulich wrote:
>> 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 logic can be added if actual problems are found with this
>> simplistic variant.)
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Reviewed-by: Paul Durrant <paul@xxxxxxx>
>> ---
>> v7: Re-base.
>> v5: New.
>>
>> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
>> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>> @@ -384,6 +384,38 @@ static int __init parse_ivmd_block(const
>>      AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
>>                      ivmd_block->header.type, start_addr, mem_length);
>>  
>> +    if ( !e820_all_mapped(base, limit + PAGE_SIZE, E820_RESERVED) )
>> +    {
>> +        paddr_t addr;
>> +
>> +        AMD_IOMMU_DEBUG("IVMD: [%lx,%lx) is not (entirely) in reserved 
>> memory\n",
>> +                        base, limit + PAGE_SIZE);
>> +
>> +        for ( addr = base; addr <= limit; addr += PAGE_SIZE )
>> +        {
>> +            unsigned int type = page_get_ram_type(maddr_to_mfn(addr));
>> +
>> +            if ( type == RAM_TYPE_UNKNOWN )
>> +            {
>> +                if ( e820_add_range(&e820, addr, addr + PAGE_SIZE,
>> +                                    E820_RESERVED) )
>> +                    continue;
>> +                AMD_IOMMU_DEBUG("IVMD Error: Page at %lx couldn't be 
>> reserved\n",
>> +                                addr);
>> +                return -EIO;
>> +            }
>> +
>> +            /* Types which won't be handed out are considered good enough. 
>> */
>> +            if ( !(type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI |
>> +                           RAM_TYPE_UNUSABLE)) )
>> +                continue;
>> +
>> +            AMD_IOMMU_DEBUG("IVMD Error: Page at %lx can't be converted\n",
>> +                            addr);
> 
> I think these print messages need to more than just debug.  The first
> one is a warning, whereas the final two are hard errors liable to impact
> the correct running of the system.

Well, people would observe IOMMUs not getting put in use. I was following
existing style in this regard on the assumption that in such an event
people would (be told to) enable "iommu=debug". Hence ...

> Especially as you're putting them in to try and spot problem cases, they
> should be visible by default for when we inevitably get bug reports to
> xen-devel saying "something changed with passthrough in Xen 4.16".

... I can convert to ordinary printk(), provided you're convinced the
described model isn't reasonable and introducing a logging inconsistency
is worth it.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.