Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751510AbdFIBNj (ORCPT ); Thu, 8 Jun 2017 21:13:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:44818 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751442AbdFIBNi (ORCPT ); Thu, 8 Jun 2017 21:13:38 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3794E239CF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 From: Andy Lutomirski Date: Thu, 8 Jun 2017 18:13:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Speeding up VMX with GDT fixmap trickery? To: X86 ML , "linux-kernel@vger.kernel.org" , kvm list , Paolo Bonzini , Borislav Petkov , Thomas Garnier , Juergen Gross , Andrew Cooper , Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1228 Lines: 28 Hi all- As promised when Thomas did his GDT fixmap work, here is a draft patch to speed up KVM by extending it. The downside of this patch is that it makes the fixmap significantly larger on 64-bit systems if NR_CPUS is large (it adds 15 more pages per CPU). I don't know if we care at all. It also bloats the kernel image by 4k and wastes 4k of RAM for the entire time the system is booted. We could avoid the latter bit (sort of) by not mapping the extra fixmap pages at all and handling the resulting faults somehow. That would scare me -- now we have IRET generating #PF when running malicious , and that way lies utter madness. The upside is that we don't need to do LGDT after a vmexit on VMX. LGDT is slooooooooooow. But no, I haven't benchmarked this yet. What do you all think? https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/kvm&id=e249a09787d6956b52d8260b2326d8f12f768799 Andrew/Boris/Juergen: what does Xen think about setting a very high GDT limit? Will it let us? Should I fix it by changing load_fixmap_gdt() (i.e. uncommenting the commented bit) or by teaching the Xen paravirt code to just ignore the monstrous limit? Or is it not a problem in the first place? --Andy