[<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