From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E6ECC433E0 for ; Wed, 27 May 2020 05:03:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6155D2078C for ; Wed, 27 May 2020 05:03:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727984AbgE0FDw (ORCPT ); Wed, 27 May 2020 01:03:52 -0400 Received: from mga02.intel.com ([134.134.136.20]:12110 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725294AbgE0FDw (ORCPT ); Wed, 27 May 2020 01:03:52 -0400 IronPort-SDR: idtH4SsVZEYvZMTG8zEKs2DTHDAkXQyLLSS2iypxRZkF7vc7JRH0Zz5lwM6S/7PdiNvNqybexQ QEll9H43bRXg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2020 22:03:51 -0700 IronPort-SDR: IDjJYMB2xhItrESlJ3Zifboi+czkTD8eZyWtdEyEMjzj7RutpCtZfFIP0/59NUCUakiJ6uxEAm YB5Mp0JYfFrQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,440,1583222400"; d="scan'208";a="310471960" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by FMSMGA003.fm.intel.com with ESMTP; 26 May 2020 22:03:50 -0700 Date: Tue, 26 May 2020 22:03:50 -0700 From: Sean Christopherson To: "Kirill A. Shutemov" Cc: Vitaly Kuznetsov , David Rientjes , Andrea Arcangeli , Kees Cook , Will Drewry , "Edgecombe, Rick P" , "Kleen, Andi" , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Paolo Bonzini , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [RFC 02/16] x86/kvm: Introduce KVM memory protection feature Message-ID: <20200527050350.GK31696@linux.intel.com> References: <20200522125214.31348-1-kirill.shutemov@linux.intel.com> <20200522125214.31348-3-kirill.shutemov@linux.intel.com> <87d06s83is.fsf@vitty.brq.redhat.com> <20200525151525.qmfvzxbl7sq46cdq@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200525151525.qmfvzxbl7sq46cdq@box> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 25, 2020 at 06:15:25PM +0300, Kirill A. Shutemov wrote: > On Mon, May 25, 2020 at 04:58:51PM +0200, Vitaly Kuznetsov wrote: > > > @@ -727,6 +734,15 @@ static void __init kvm_init_platform(void) > > > { > > > kvmclock_init(); > > > x86_platform.apic_post_init = kvm_apic_init; > > > + > > > + if (kvm_para_has_feature(KVM_FEATURE_MEM_PROTECTED)) { > > > + if (kvm_hypercall0(KVM_HC_ENABLE_MEM_PROTECTED)) { > > > + pr_err("Failed to enable KVM memory protection\n"); > > > + return; > > > + } > > > + > > > + mem_protected = true; > > > + } > > > } > > > > Personally, I'd prefer to do this via setting a bit in a KVM-specific > > MSR instead. The benefit is that the guest doesn't need to remember if > > it enabled the feature or not, it can always read the config msr. May > > come handy for e.g. kexec/kdump. > > I think we would need to remember it anyway. Accessing MSR is somewhat > expensive. But, okay, I can rework it MSR if needed. I think Vitaly is talking about the case where the kernel can't easily get at its cached state, e.g. after booting into a new kernel. The kernel would still have an X86_FEATURE bit or whatever, providing a virtual MSR would be purely for rare slow paths. That being said, a hypercall plus CPUID bit might be better, e.g. that'd allow the guest to query the state without risking a #GP. > Note, that we can avoid the enabling algother, if we modify BIOS to deal > with private/shared memory. Currently BIOS get system crash if we enable > the feature from time zero. Which would mesh better with a CPUID feature bit.