[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6CAE8F45-E2C0-453F-B2C8-12D9BBE6B8D7@oracle.com>
Date: Mon, 13 May 2019 18:17:42 +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 01/27] kernel: Export memory-management symbols required
for KVM address space isolation
> On 13 May 2019, at 18:15, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Mon, May 13, 2019 at 04:38:09PM +0200, Alexandre Chartre wrote:
>> From: Liran Alon <liran.alon@...cle.com>
>>
>> Export symbols needed to create, manage, populate and switch
>> a mm from a kernel module (kvm in this case).
>>
>> This is a hacky way for now to start.
>> This should be changed to some suitable memory-management API.
>
> This should not be exported at all, ever, end of story.
>
> Modules do not get to play with address spaces like that.
I agree… No doubt about that. This should never be merged like this.
It’s just to have an initial PoC of the concept so we can:
1) Messure performance impact of concept.
2) Get feedback on appropriate design and APIs from community.
-Liran
Powered by blists - more mailing lists