lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 1 Sep 2016 15:55:25 +0100 From: Will Deacon <will.deacon@....com> To: Punit Agrawal <punit.agrawal@....com> Cc: kvm@...r.kernel.org, Marc Zyngier <marc.zyngier@....com>, linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...hat.com>, kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org Subject: Re: [RFC PATCH 6/7] arm64: KVM: Handle trappable TLB instructions On Fri, Aug 26, 2016 at 10:37:08AM +0100, Punit Agrawal wrote: > > Will Deacon <will.deacon@....com> writes: > >> The easiest thing to do is just TLBI VMALLE1IS for all trapped operations, > >> but you might want to see how that performs. > > > > That sounds reasonable for correctness. But I suspect we'll have to do > > more to claw back some performance. Let me run a few tests and come back > > on this. > > Assuming I've correctly switched in TCR and replacing the various TLB > operations in this patch with TLBI VMALLE1IS, there is a drop in kernel > build times of ~5% (384s vs 363s). What do you mean by "switched in TCR"? Why is that necessary if you just nuke the whole thing? Is the ~5% relative to no trapping at all, or trapping, but being selective about the operation? Will
Powered by blists - more mailing lists