Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.117.161 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C
Message-ID: <bd235db0-8355-2038-3b71-3b17cde91293@nvidia.com>
Date:   Thu, 29 Sep 2022 19:31:03 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: some likely bugs in IOMMUv2 (in tlb_finish_mmu() nested flush and
 mremap())
Content-Language: en-US
To:     Jason Gunthorpe <jgg@nvidia.com>,
        Sean Christopherson <seanjc@google.com>,
        David Hildenbrand <david@redhat.com>
CC:     Jann Horn <jannh@google.com>, Will Deacon <will@kernel.org>,
        Joerg Roedel <jroedel@suse.de>,
        <jean-philippe.brucker@arm.com>, Linux-MM <linux-mm@kvack.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        <iommu@lists.linux.dev>
References: <CAG48ez2NQKVbv=yG_fq_jtZjf8Q=+Wy54FxcFrK_OujFg5BwSQ@mail.gmail.com>
 <Yy3skVk/DvwVnPXD@nvidia.com> <YzIHzIxknGNba6CC@google.com>
 <YzI2jzvc8D9lYU6G@nvidia.com> <YzJCyTD4kBSt3VlU@google.com>
 <YzSOfHUMGjjQiSNZ@nvidia.com>
From:   John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <YzSOfHUMGjjQiSNZ@nvidia.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2022 02:31:21.3152
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4dcba1b3-e74e-4d00-d5e1-08daa28bdcc9
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT020.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4483
X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 9/28/22 11:12, Jason Gunthorpe wrote:
> On Tue, Sep 27, 2022 at 12:24:41AM +0000, Sean Christopherson wrote:
>> On Mon, Sep 26, 2022, Jason Gunthorpe wrote:
>>> On Mon, Sep 26, 2022 at 08:13:00PM +0000, Sean Christopherson wrote:
>>>
>>>>> AFAIK if we are flushing the CPU tlb then we really must also flush
>>>>> the CPU tlb that KVM controls, and that is primarily what
>>>>> invalidate_range() is used for.
>>>>
>>>> As above, for its actual secondary MMU, KVM invalidates and flushes at
>>>> invalidate_range_start(), and then prevents vCPUs from creating new entries for
>>>> the range until invalidate_range_start_end().
>>>
>>> Was it always like this? Why did we add this invalidate_range thing if
>>> nothing really needed it?
>>
>> No, the invalidate_range() hook was added by commit 1897bdc4d331 ("mmu_notifier:
>> add mmu_notifier_invalidate_range()") for IOMMUs.
> 
> Ah, right OK. This is specifically because the iommu is sharing the
> *exact* page table of the CPU so the trick KVM/etc uses where 'start'
> makes the shadow PTE non-present and then delays the fault until end
> completes cannot work here.

ohhh, is this trick something I should read more about, if I'm about to
jump in here?

> 
>>      The page-fault handler in the AMD IOMMUv2 driver doesn't handle the fault
>>      if an invalidate_range_start/end pair is active, it just reports back
>>      SUCCESS to the device and let it refault the page.
> 
> Yah, this algorithm just doesn't really work, IMHO.. So it makes sense
> we have invalidate_range as Joerg originally created it. Though the
> GPU is still busted IMHO, there is no guarantee of forward progress
> after some number of iterations, it is just much more likely if the
> non-present is as narrow as possible.
> 
> So, then we can see where the end_only thing came from, commit
> 0f10851ea475 ("mm/mmu_notifier: avoid double notification when it is
> useless") and that long winded message explains why some of the cases

I seem to recall that there was a performance drop involving GPUs, due
to the double notification. Just to fill in a little bit of history as
to why Jerome was trying to deduplicate the notifier callbacks.

> must be ordered in the same place as the CPU flush, but doesn't
> explain very much why it is OK to push it after beyond saying "ksm is
> OK"
> 
> Looking at some of the places where 0f10851ea475 removed the notifies
> they seem pretty pointless.
> 
> - fs/dax.c
>    This never needed notify in the first place, it is populating a
>    non-present PTE because it just faulted.
> 
> - __split_huge_zero_page_pmd()
>    Sure, maybe, but who cares? The real fix here was changing
>    __split_huge_pmd() to use only_end() because all paths already
>    call invalidate_range
> 
> - copy_hugetlb_page_range()
>    Sure, there is no CPU tlb flush.
> 
>    The CPU tlb flush on this path is in flush_tlb_mm() called by
>    dup_mmap().
> 
>    The right thing to do is to ensure flush_tlb_mm() calls
>    invalidate_range and skip it here. But the reasoning is not some
>    "we are downgrading protections blah blah", the logic is that the
>    CPU TLB flush can be delayed/consolidated so we can delay the
>    shadow TLB flush too.
> 
>    (And why does copy_hugetlb_page_range use MMU_NOTIFY_CLEAR but
>     copy_p4d_range is bounded by MMU_NOTIFY_PROTECTION_PAGE ??)
> 
> - hugetlb_change_protection()
>    Again I feel like the sensible thing here is to trigger the shadow
>    flush in flush_hugetlb_tlb_range() always and use end_only
> 
> .. and so on ..
> 
> So, IMHO, we need to rewrite what 0f10851ea475 was trying to do in
> order to fix the bug Jann noticed :\  That is bigger than I can knock
> off while I write this email though ..

After an initial pass through this, with perhaps 80% understanding
of the story, I'm reading that as:

     Audit all the sites (which you initially did quickly, above)
     that 0f10851ea475 touched, and any other related ones, and
     change things so that invalidate_range() and primary TLB
     flushing happen at the same point(s).

Yes? Anything else?

thanks,
-- 
John Hubbard
NVIDIA

> 
>>> That means iommu is really the only place using it as a proper
>>> synchronous shadow TLB flush.
>>
>> More or less. There's also an "OpenCAPI coherent accelerator
>> support" driver, drivers/misc/ocxl, that appears use
>> invalidate_range() the same way the IOMMU does.  No idea how
>> relevant that is these days.
> 
> Yeah, OpenCAPI is the same stuff as the IOMMU. Just PPC got away with
> building all their IOMMU layer in its own arch specific subsystem :|
> 
>> I much prefer KVM's (and the old IOMMU's) approach of re-faulting in hardware until
>> the entire sequence completes.   It _might_ be less performant, but I find it so
>> much easier to reason about.  I actually had typed out a "can we just kill off
>> mmu_notifier_invalidate_range() and force users to refault hardware" question
>> before seeing the above changelog.
> 
> The key thing this requires is the ability to put the hardware into
> fault mode (non-present), for the range under invalidation. If you
> can't do that, then you can't use it.
> 
>> I don't know.  I found the series that introduced the behavior[*], but there are
>> no numbers provided and I haven't been able to dredge up why this was even looked
>> into in the first place.  From the cover letter:
> 
> It looks like a 'by inspection' project..
> 
>> If I had a vote to cast, I would vote to always do invalidate_range() at the same
>> time the primary TLBs are flushed.  That seems completely logical and much harder
>> to screw up.  I might be a little biased though since KVM doesn't benefit from the
>> current shenanigans :-)
> 
> Me too.
> 
> Jason
>