From patchwork Wed Nov 30 04:11:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Education Directorate X-Patchwork-Id: 9453561 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0541760585 for ; Wed, 30 Nov 2016 04:11:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F223E1FF28 for ; Wed, 30 Nov 2016 04:11:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E69A228426; Wed, 30 Nov 2016 04:11:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B98B81FF28 for ; Wed, 30 Nov 2016 04:11:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756034AbcK3ELP (ORCPT ); Tue, 29 Nov 2016 23:11:15 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:33178 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754020AbcK3ELN (ORCPT ); Tue, 29 Nov 2016 23:11:13 -0500 Received: by mail-pg0-f65.google.com with SMTP id 3so1023pgd.0; Tue, 29 Nov 2016 20:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:subject:cc:from:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=KM3QwpgJZQtjsrcWWtyeQ4eUeGmkwfaNicp3AwUpJ6c=; b=BHx0I+h2kzMoH4ulCsJnLEQbwbRGTK/ark1Cs9LhhwTV5q9dmHdd+AyUcEBP9mqI7T hnsAuKg/XdWaVvH7669FxCDpLFNWdCV9LmCHt/0t1oI8BDFX/ZSAubuyP3cuM9vdTs7x TSglhFD4OQgivmE2Q3wqOWB3NPx0Kk0Dvv2fF10aVpAIsAkqtNIVwjwgBBqL6Zuum/6N GB5NGO2qCv35BdezWO4z6geA/4AvGzthzw4z4JggYekx78TmwwU1lo1NztQ4RYj3T/8t Vc6l3YF2XNKWwRnIIejaWbG6KLjUK+nY89j4E+FGj+RzshdwS0bq2Al2TL76XoUiOBF7 x7Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:subject:cc:from:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=KM3QwpgJZQtjsrcWWtyeQ4eUeGmkwfaNicp3AwUpJ6c=; b=RWwbXYoy773BTk1vjtirQ6cg0YQmAMSD2ksmRvZ/i0AKhJzfJ3vKQYUhstvThaS8Da 3F8A+xJG8TUk3xEj8ZLx0dnXlKZq5JMRTOSZD+vuVYt3AMNiCLWcLCrVsb/CqqQZH1JY drEmmoE5/N7XrBYjQrEc5czBtjvTCKg3+0ZBzwgL3LtgOJNTOwGymV/nSoAXHO4KYv3f fRmxcNG9AGaj+2syR/iLvXOe6E+zje1EHw7O/nxwuqLTNsbf9BNxjYNeb8oEiy9bOlBP Qx/U1IHC5KPFzzhOo3kXnKpJl7uNXCA1uuav5TWfS/MVudoOOFjYs7P4EdAI6QVGWnKZ /zOQ== X-Gm-Message-State: AKaTC02BD5YnloIUsYL/yHEX8DhcPE4YN2uXhn0Sh4nHFbV30MYbuuqt/H4XMoqzDGYPHw== X-Received: by 10.99.136.194 with SMTP id l185mr56348086pgd.106.1480479072673; Tue, 29 Nov 2016 20:11:12 -0800 (PST) Received: from balbir.ozlabs.ibm.com ([122.99.82.10]) by smtp.gmail.com with ESMTPSA id g22sm80514700pgn.20.2016.11.29.20.11.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 20:11:12 -0800 (PST) To: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH v2] KVM/PPC Patch for KVM issue in real mode Cc: Paul Mackerras , Paolo Bonzini , Radim , linuxppc-dev From: Balbir Singh Message-ID: <20a3e138-8a6e-6ad8-b9ba-ec8332f011a5@gmail.com> Date: Wed, 30 Nov 2016 15:11:06 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some KVM functions for book3s_hv are called in real mode. In real mode the top 4 bits of the address space are ignored, hence an address beginning with 0xc0000000+offset is the same as 0xd0000000+offset. The issue was observed when a kvm memslot resolution lead to random values when access from kvmppc_h_enter(). The issue is hit if the KVM host is running with a page size of 4K, since kvzalloc() looks at size < PAGE_SIZE. On systems with 64K the issue is not observed easily, it largely depends on the size of the structure being allocated. The proposed fix moves all KVM allocations for book3s_hv to kzalloc() until all structures used in real mode are audited. For safety allocations are moved to kmalloc space. The impact is a large allocation on systems with 4K page size. Signed-off-by: Balbir Singh --- Changelog v2: Fix build failures reported by the kbuild test robot http://www.spinics.net/lists/kvm/msg141727.html arch/powerpc/include/asm/kvm_host.h | 19 +++++++++++++++++++ include/linux/kvm_host.h | 11 +++++++++++ virt/kvm/kvm_main.c | 2 +- 3 files changed, 31 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h index f15713a..53f5172 100644 --- a/arch/powerpc/include/asm/kvm_host.h +++ b/arch/powerpc/include/asm/kvm_host.h @@ -734,6 +734,25 @@ struct kvm_vcpu_arch { #define __KVM_HAVE_ARCH_WQP #define __KVM_HAVE_CREATE_DEVICE +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE +#define __KVM_HAVE_ARCH_VZALLOC_OVERRIDE + +/* + * KVM uses some of these data structures -- the ones + * from kvzalloc() in real mode. If the data structure + * happens to come from a vmalloc'd range then its access + * in real mode will lead to problems due to the aliasing + * issue - (top 4 bits are ignore). + * A 0xd000+offset will point to a 0xc000+offset in realmode + * Hence we want our data structures from come from kmalloc'd + * regions, so that we don't have these aliasing issues + */ +static inline void *kvm_arch_vzalloc(unsigned long size) +{ + return kzalloc(size, GFP_KERNEL); +} +#endif + static inline void kvm_arch_hardware_disable(void) {} static inline void kvm_arch_hardware_unsetup(void) {} static inline void kvm_arch_sync_events(struct kvm *kvm) {} diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 01c0b9c..0c88af5 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -793,6 +794,16 @@ static inline bool kvm_arch_has_noncoherent_dma(struct kvm *kvm) return false; } #endif + +#ifdef __KVM_HAVE_ARCH_VZALLOC_OVERRIDE +static void *kvm_arch_vzalloc(unsigned long size); +#else +static inline void *kvm_arch_vzalloc(unsigned long size) +{ + return vzalloc(size); +} +#endif + #ifdef __KVM_HAVE_ARCH_ASSIGNED_DEVICE void kvm_arch_start_assignment(struct kvm *kvm); void kvm_arch_end_assignment(struct kvm *kvm); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index fbf04c0..57e3dca 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -689,7 +689,7 @@ static struct kvm *kvm_create_vm(unsigned long type) void *kvm_kvzalloc(unsigned long size) { if (size > PAGE_SIZE) - return vzalloc(size); + return kvm_arch_vzalloc(size); else return kzalloc(size, GFP_KERNEL); }