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

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 10 May 2023 12:00:51 +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=fKYiWpXDCM+z2qrWJWYHeIba4Y+0XKQKAWBJxbyEV8U=; b=USEOvp5Wdr4qBa1n1I9T08tlhDW1G5Kjp8curlMfViyCAVUgy3sRrOe2aCIr1urwUSAZazCW+FjfCmbPskJOYvkQCNISfHFXsjyVik1jalw7hshGHmjJijPCYRDcbxLL+TlRCXxt+nHl3AyQhfBA5Y+5PmJU7hdhDWT/fDcQrqP6nRRJ9Nde7l+YTTPD19W5JFOejvatqBvvoEeGVppa8geduFd2U2xO8Wavl7Ixi3X0wu5x0L3LGuadZf4YQ44veE+iyaL7AanF4K1qBSQIWQ/kgD4nGKrPozbUW+rmMgqnEOiyjiP/PnUY6prctsCGhzkI8SYDbsrSvp+ZWSdPEA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YXYvn9/tUjqZ7DZ9Y+M0YYKCABtFHH6FEscgAkav9ylHZFQ++y1dZykYO5KUDcV8ovYZob9m3Y6cmovEX6jXaKk8VtHBZCHO8yoojbiWxDehatkVeeSzhcSGlfHYG8XeWexkNPfT1q2/GrYeQvZEOFCVF1aHhPxGEcm7vnCKRH0KvV/nXORhmejYj8fiCAUnKYsrr6i8kOTcfVjAYo7EIrNDfYJgHRODvpVYoO3bUD00JkbeZjsUEaZRC8xGu5K0hcvDbDpb36QYa8yMC5Q26M4f1DBav35wSEGe5NhiUJe6gdxP8xB9zZxvB5lNwRuzgK6yf/otAq7YXb8Vq7l7Hg==
  • 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: Wed, 10 May 2023 10:01:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.05.2023 10:27, Roger Pau Monné wrote:
> On Tue, May 09, 2023 at 06:06:45PM +0200, Jan Beulich wrote:
>> 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.
> 
> Hm, but the code in intel_iommu_lookup_page() is now wrong as it takes
> the bits in DMA_PTE_CONTIG_MASK as part of the physical address when
> doing the conversion to mfn?  maddr_to_mfn() doesn't perform a any
> masking to remove the bits above PADDR_BITS.

Oh, right. But that's a missing dma_pte_addr() in intel_iommu_lookup_page()
then. (It would likely be better anyway to switch "uint64_t val" to
"struct dma_pte pte" there, to make more visible that it's a PTE we're
dealing with.) I indeed overlooked this aspect when doing the earlier
change.

Jan



 


Rackspace

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