[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <543a134e-26ef-46c8-9f4e-c37e24dd7a25@redhat.com>
Date: Tue, 21 Jan 2025 08:46:04 +0100
From: David Hildenbrand <david@...hat.com>
To: Rik van Riel <riel@...riel.com>, x86@...nel.org
Cc: linux-kernel@...r.kernel.org, bp@...en8.de, peterz@...radead.org,
dave.hansen@...ux.intel.com, zhengqi.arch@...edance.com,
nadav.amit@...il.com, thomas.lendacky@....com, kernel-team@...a.com,
linux-mm@...ck.org, akpm@...ux-foundation.org, jannh@...gle.com,
mhklinux@...look.com, andrew.cooper3@...rix.com
Subject: Re: [PATCH v6 02/12] x86/mm: remove pv_ops.mmu.tlb_remove_table call
On 21.01.25 02:03, Rik van Riel wrote:
> On Mon, 2025-01-20 at 20:47 +0100, David Hildenbrand wrote:
>> On 20.01.25 03:40, Rik van Riel wrote:
>>> Every pv_ops.mmu.tlb_remove_table call ends up calling
>>> tlb_remove_table.
>>>
>>
>> Indeed, but the !CONFIG_PARAVIRT variant paravirt_tlb_remove_table()
>> however calls tlb_remove_page().
>
> Patch 1/12 from this series removes that.
>
> After patch 1/12, we always call tlb_remove_table everywhere.
This patch contains the hunk:
-#ifndef CONFIG_PARAVIRT
-static inline
-void paravirt_tlb_remove_table(struct mmu_gather *tlb, void *table)
-{
- tlb_remove_page(tlb, table);
-}
-#endif
-
That is the source of my confusion.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists