On Thu, Nov 30, 2017 at 12:01 PM, Peter Zijlstra wrote:
> On Thu, Nov 30, 2017 at 10:48:56AM -0800, Andy Lutomirski wrote:
>> Should it be
>> tlb_flush_shared_nonglobals_if_kernel_and_user_pagetables_are_separate()?
>
> Its effectively invpcid_flush_all_other() or something like that. Of
> course
On Thu, Nov 30, 2017 at 10:48:56AM -0800, Andy Lutomirski wrote:
> Should it be
> tlb_flush_shared_nonglobals_if_kernel_and_user_pagetables_are_separate()?
Its effectively invpcid_flush_all_other() or something like that. Of
course, its not invpcid based, so we should not name it such.
flush_asi
On Thu, Nov 30, 2017 at 11:00:06AM -0800, Dave Hansen wrote:
> On 11/30/2017 10:55 AM, Peter Zijlstra wrote:
> >> __flush_tlb() does a flushing CR3 write that flushes the current PCID.
> >> If we need other PCIDs flushed, we have to do it via the
> >> tlb_flush_shared_nonglobals() mechanism.
> > Bu
On 11/30/2017 10:55 AM, Peter Zijlstra wrote:
>> __flush_tlb() does a flushing CR3 write that flushes the current PCID.
>> If we need other PCIDs flushed, we have to do it via the
>> tlb_flush_shared_nonglobals() mechanism.
> But the thing is, you _cannot_ have PCID enabled in that branch.
Is ther
On Thu, Nov 30, 2017 at 10:44:40AM -0800, Dave Hansen wrote:
> On 11/30/2017 08:18 AM, Peter Zijlstra wrote:
> > On Thu, Nov 30, 2017 at 07:51:17AM -0800, Dave Hansen wrote:
> >> On 11/30/2017 07:44 AM, Peter Zijlstra wrote:
> >>> On Mon, Nov 27, 2017 at 11:49:14AM +0100, Ingo Molnar wrote:
>
On 11/30/2017 10:48 AM, Andy Lutomirski wrote:
>> __flush_tlb() does a flushing CR3 write that flushes the current PCID.
>> If we need other PCIDs flushed, we have to do it via the
>> tlb_flush_shared_nonglobals() mechanism.
>>
>> Does it matter today in practice? Nope, we never have that situatio
On Thu, Nov 30, 2017 at 10:44 AM, Dave Hansen
wrote:
> On 11/30/2017 08:18 AM, Peter Zijlstra wrote:
>> On Thu, Nov 30, 2017 at 07:51:17AM -0800, Dave Hansen wrote:
>>> On 11/30/2017 07:44 AM, Peter Zijlstra wrote:
On Mon, Nov 27, 2017 at 11:49:14AM +0100, Ingo Molnar wrote:
> @@ -338,24
On 11/30/2017 08:18 AM, Peter Zijlstra wrote:
> On Thu, Nov 30, 2017 at 07:51:17AM -0800, Dave Hansen wrote:
>> On 11/30/2017 07:44 AM, Peter Zijlstra wrote:
>>> On Mon, Nov 27, 2017 at 11:49:14AM +0100, Ingo Molnar wrote:
@@ -338,24 +366,23 @@ static inline void
__native_flush_tlb_singl
On Thu, Nov 30, 2017 at 07:51:17AM -0800, Dave Hansen wrote:
> On 11/30/2017 07:44 AM, Peter Zijlstra wrote:
> > On Mon, Nov 27, 2017 at 11:49:14AM +0100, Ingo Molnar wrote:
> >> @@ -338,24 +366,23 @@ static inline void
> >> __native_flush_tlb_single(unsigned long addr)
> >>
> >> static inline
On 11/30/2017 07:44 AM, Peter Zijlstra wrote:
> On Mon, Nov 27, 2017 at 11:49:14AM +0100, Ingo Molnar wrote:
>> @@ -338,24 +366,23 @@ static inline void __native_flush_tlb_single(unsigned
>> long addr)
>>
>> static inline void __flush_tlb_all(void)
>> {
>> +if (boot_cpu_has(X86_FEATURE_PGE
On Mon, Nov 27, 2017 at 11:49:14AM +0100, Ingo Molnar wrote:
> @@ -338,24 +366,23 @@ static inline void __native_flush_tlb_single(unsigned
> long addr)
>
> static inline void __flush_tlb_all(void)
> {
> + if (boot_cpu_has(X86_FEATURE_PGE)) {
> __flush_tlb_global();
> + }
On Thu, Nov 30, 2017 at 7:40 AM, Peter Zijlstra wrote:
> On Mon, Nov 27, 2017 at 09:16:19PM -0800, Andy Lutomirski wrote:
>> We've gotten away with having a single
>> function for both this long because we've never had PCID on and
>> nonglobal kernel mappings around. So we're busted starting with
On Mon, Nov 27, 2017 at 09:16:19PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 27, 2017 at 2:49 AM, Ingo Molnar wrote:
> > From: Dave Hansen
> >
> > If changing the page tables in such a way that an invalidation of
> > all contexts (aka. PCIDs / ASIDs) is required, they can be
> > actively invali
On Tue, Nov 28, 2017 at 12:34:17PM -0800, Andy Lutomirski wrote:
> I think it should be fine. A very old version of the patches had that
> problem, but, in -tip, the nmi RESTORE_CR3 is in the fancy
> recursion-protected region, and the stack is okay. The idea is that
> we're already on the old (p
On Tue, Nov 28, 2017 at 12:34:17PM -0800, Andy Lutomirski wrote:
> Side question: on extremely quick read, you're doing bt then btr. Why
> not just do a single btr and be done with it? Are you trying to avoid
> getting exclusive access to the cacheline when not needed?
Yes, avoids the M in the c
On Tue, Nov 28, 2017 at 11:05 AM, Peter Zijlstra wrote:
> On Tue, Nov 28, 2017 at 10:13:30AM -0800, Dave Hansen wrote:
>> Thanks for looking at this, Peter. I've been resisting doing this for a
>> bit and it's an embarrassingly small amount of code.
>
> Right, well, its not complete yet, and it m
On Tue, Nov 28, 2017 at 08:05:05PM +0100, Peter Zijlstra wrote:
> I'm now staring at the RESTORE_CR3 stuff, and that appears to be called
> in the NMI handling where the stack is not to be used (if I read it
> right), so that's going to be a little more tricky.
As I just mentioned on IRC; I just r
On Tue, Nov 28, 2017 at 10:13:30AM -0800, Dave Hansen wrote:
> Thanks for looking at this, Peter. I've been resisting doing this for a
> bit and it's an embarrassingly small amount of code.
Right, well, its not complete yet, and it might be complete crap :-)
> On 11/28/2017 08:39 AM, Peter Zijls
Thanks for looking at this, Peter. I've been resisting doing this for a
bit and it's an embarrassingly small amount of code.
On 11/28/2017 08:39 AM, Peter Zijlstra wrote:
> @@ -220,7 +221,21 @@ For 32-bit we have the following conventions - kernel is
> built with
> .macro SWITCH_TO_USER_CR3 scr
On Tue, Nov 28, 2017 at 05:39:08PM +0100, Peter Zijlstra wrote:
> @@ -220,7 +221,21 @@ For 32-bit we have the following conventions - kernel is
> built with
> .macro SWITCH_TO_USER_CR3 scratch_reg:req
> STATIC_JUMP_IF_FALSE .Lend_\@, kaiser_enabled_key, def=1
> mov %cr3, \scratch
On Mon, Nov 27, 2017 at 09:16:19PM -0800, Andy Lutomirski wrote:
> We need to split up __flush_tlb_one() into __flush_tlb_one() and
> __flush_tlb_one_kernel(). We've gotten away with having a single
> function for both this long because we've never had PCID on and
> nonglobal kernel mappings aroun
On 11/27/2017 09:16 PM, Andy Lutomirski wrote:
> We need to split up __flush_tlb_one() into __flush_tlb_one() and
> __flush_tlb_one_kernel(). We've gotten away with having a single
> function for both this long because we've never had PCID on and
> nonglobal kernel mappings around. So we're buste
On Mon, Nov 27, 2017 at 2:49 AM, Ingo Molnar wrote:
> From: Dave Hansen
>
> If changing the page tables in such a way that an invalidation of
> all contexts (aka. PCIDs / ASIDs) is required, they can be
> actively invalidated by:
>
> 1. INVPCID for each PCID (works for single pages too).
>
> 2.
23 matches
Mail list logo
