[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <13F2FA4F-116F-40C6-9472-A1DE689FE061@oracle.com>
Date: Tue, 14 May 2019 00:25:44 +0300
From: Liran Alon <liran.alon@...cle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Alexandre Chartre <alexandre.chartre@...cle.com>,
pbonzini@...hat.com, rkrcmar@...hat.com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, hpa@...or.com,
dave.hansen@...ux.intel.com, luto@...nel.org, kvm@...r.kernel.org,
x86@...nel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
konrad.wilk@...cle.com, jan.setjeeilers@...cle.com,
jwadams@...gle.com
Subject: Re: [RFC KVM 24/27] kvm/isolation: KVM page fault handler
> On 13 May 2019, at 18:15, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Mon, May 13, 2019 at 04:38:32PM +0200, Alexandre Chartre wrote:
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index 46df4c6..317e105 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -33,6 +33,10 @@
>> #define CREATE_TRACE_POINTS
>> #include <asm/trace/exceptions.h>
>>
>> +bool (*kvm_page_fault_handler)(struct pt_regs *regs, unsigned long error_code,
>> + unsigned long address);
>> +EXPORT_SYMBOL(kvm_page_fault_handler);
>
> NAK NAK NAK NAK
>
> This is one of the biggest anti-patterns around.
I agree.
I think that mm should expose a mm_set_kvm_page_fault_handler() or something (give it a better name).
Similar to how arch/x86/kernel/irq.c have kvm_set_posted_intr_wakeup_handler().
-Liran
Powered by blists - more mailing lists