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 0AEC0C433DF for ; Wed, 27 May 2020 05:03:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C74052078C for ; Wed, 27 May 2020 05:03:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C74052078C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3FBBA800B6; Wed, 27 May 2020 01:03:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3AB2B80010; Wed, 27 May 2020 01:03:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 299B2800B6; Wed, 27 May 2020 01:03:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 1F9C380010 for ; Wed, 27 May 2020 01:03:54 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DE66A181AC9C6 for ; Wed, 27 May 2020 05:03:53 +0000 (UTC) X-FDA: 76861306746.11.cause82_32004fa26d4f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id B3479180F8B80 for ; Wed, 27 May 2020 05:03:53 +0000 (UTC) X-HE-Tag: cause82_32004fa26d4f X-Filterd-Recvd-Size: 3880 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 May 2020 05:03:52 +0000 (UTC) IronPort-SDR: Sm7CsE+ZeEajh93p7icZBhSqd38OFQRtz1kdWR68Gg5Ml4s+07AGix3E1gTtxWzP8g7gBUnZBI 5XzXGpM1u71Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.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) X-Rspamd-Queue-Id: B3479180F8B80 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.