[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F609AED4-2238-43E0-8095-1659F945E277@gmail.com>
Date: Thu, 18 Mar 2021 00:48:37 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)"
<longpeng2@...wei.com>
Cc: Lu Baolu <baolu.lu@...ux.intel.com>,
Alex Williamson <alex.williamson@...hat.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"joro@...tes.org" <joro@...tes.org>,
"will@...nel.org" <will@...nel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Gonglei (Arei)" <arei.gonglei@...wei.com>,
chenjiashang <chenjiashang@...wei.com>,
"Subo (Subo, Cloud Infrastructure Service Product Dept.)"
<subo7@...wei.com>
Subject: Re: A problem of Intel IOMMU hardware ?
> On Mar 17, 2021, at 9:46 PM, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) <longpeng2@...wei.com> wrote:
>
[Snip]
>
> NOTE, the magical thing happen...(*Operation-4*) we write the PTE
> of Operation-1 from 0 to 0x3 which means can Read/Write, and then
> we trigger DMA read again, it success and return the data of HPA 0 !!
>
> Why we modify the older page table would make sense ? As we
> have discussed previously, the cache flush part of the driver is correct,
> it call flush_iotlb after (b) and no need to flush after (c). But the result
> of the experiment shows the older page table or older caches is effective
> actually.
>
> Any ideas ?
Interesting. Sounds as if there is some page-walk cache that was not
invalidated properly.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists