[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1d1d375-53e4-58ba-7753-d01e7b3fa10f@intel.com>
Date: Mon, 17 Jun 2019 11:49:53 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Nadav Amit <nadav.amit@...il.com>, Andy Lutomirski <luto@...nel.org>,
Alexander Graf <graf@...zon.com>, Thomas Gleixner <tglx@...utronix.de>,
Marius Hillenbrand <mhillenb@...zon.de>, kvm list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linux-MM <linux-mm@...ck.org>, Alexander Graf <graf@...zon.de>,
David Woodhouse <dwmw@...zon.co.uk>,
the arch/x86 maintainers <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC 00/10] Process-local memory allocations for hiding KVM
secrets
On 6/17/19 11:45 AM, Konrad Rzeszutek Wilk wrote:
>> The idea is that you have a per-cpu address space. Certain kernel
>> virtual addresses would map to different physical address based on where
>> you are running. Each of the physical addresses would be "owned" by a
>> single CPU and would, by convention, never use a PGD that mapped an
>> address unless that CPU that "owned" it.
>>
>> In that case, you never really invalidate those addresses.
> But you would need to invalidate if the process moved to another CPU, correct?
If you have a per-cpu PGD, the rule is that you never use the PGD on
more than one CPU. In that model, processes "take over" an existing PGD
to run on the CPU rather than having the CPU use an existing PGD that
came with the process.
But we've really hijacked the original thread at this point, which is
probably causing a ton of confusion.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
