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

Re: [PATCH] iommu/vtd: fix address translation for superpages


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 9 May 2023 18:06:45 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E4bY/LJ2S4yEbyQjwXlFZ98iAIm3DE0husNP6Aq8f3A=; b=cvGv28AX+xCdCe3NXrJDV6a36uGzRObUqPqp4kfXqviwWrVNEkeM49HrpYaAwkxO4sk9ohrYMUrsulDJs7EVPHENH9e48mH7se4iav0LgrwTkTQaRAztZHL4nd0R33kr9WFNo19BbVTvLbem4z0UKesKVHUCLV/rF7jx+unHobDFZ7cRYDAnoIE/soSztb5Pr+PDQ//PgwYO9rvttfWoxWWbIJhc4yrjJw+BOqL/nPz4FHY3lff0QmkLdS8bCv+7RUyUREokDGeytwkgupj2fFYs00SCdqrRJsy0xQRHPdF2IXDjfb2ZuLUwSpPnxe/FJv7/kaG8buCQeREqd0YQcg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M/aAe4/ecbZj1RKXN4pQn959ccSSYwhtW85HEwMRS1QI5Y+tK08qwEvzoTgYirE202JSIxkUYzF2X+cXvjoHTX+OuxB1c4ZW88MybtvFmeo093CVOHbsEo0I/rETAEU4XzOkqYfHd2iAOK2F3M0AFBm724mUOCW3UXeMtIYXya/kuLighU52Nugw7sSC7bwR65YMEyVgTRxbYX7waHIgw9KqTCLGMkJasFeC34Lip20wFFzzIEyTA51UGuo02FFEyJr/6cPa9hrGnsRgoF37VaV2fR/P/luObS17LgUNwvWxJFViTevC0vo6B/J99uqtjGTxHqVaohInO1T55MrNbA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Kevin Tian <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 09 May 2023 16:06:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09.05.2023 12:41, Roger Pau Monne wrote:
> When translating an address that falls inside of a superpage in the
> IOMMU page tables the fetching of the PTE physical address field
> wasn't using dma_pte_addr(), which caused the returned data to be
> corrupt as it would contain bits not related to the address field.

I'm afraid I don't understand:

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -359,16 +359,18 @@ static uint64_t addr_to_dma_page_maddr(struct domain 
> *domain, daddr_t addr,
>  
>              if ( !alloc )
>              {
> -                pte_maddr = 0;
>                  if ( !dma_pte_present(*pte) )
> +                {
> +                    pte_maddr = 0;
>                      break;
> +                }
>  
>                  /*
>                   * When the leaf entry was requested, pass back the full PTE,
>                   * with the address adjusted to account for the residual of
>                   * the walk.
>                   */
> -                pte_maddr = pte->val +
> +                pte_maddr +=
>                      (addr & ((1UL << level_to_offset_bits(level)) - 1) &
>                       PAGE_MASK);

With this change you're now violating what the comment says (plus what
the comment ahead of the function says). And it says what it says for
a reason - see intel_iommu_lookup_page(), which I think your change is
breaking.

Note also the following code:

                if ( !target )
                    break;
            }

            pte_maddr = level - 1;

IOW the local variable is overwritten right away unless target == 0.

Jan



 


Rackspace

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