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,URIBL_BLOCKED,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 DB16AC433E2 for ; Wed, 27 May 2020 08:52:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9CF5C2078B for ; Wed, 27 May 2020 08:52:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9CF5C2078B 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 1A9D2800BD; Wed, 27 May 2020 04:52:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1327580010; Wed, 27 May 2020 04:52:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3C77800BD; Wed, 27 May 2020 04:52:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D9EA580010 for ; Wed, 27 May 2020 04:52:17 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 922836D9B for ; Wed, 27 May 2020 08:52:17 +0000 (UTC) X-FDA: 76861882314.16.lake43_140025226d50 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 6E4A8100E6929 for ; Wed, 27 May 2020 08:52:17 +0000 (UTC) X-HE-Tag: lake43_140025226d50 X-Filterd-Recvd-Size: 4909 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 May 2020 08:52:15 +0000 (UTC) IronPort-SDR: h1K6Lw6dWzLwd9JKhp10mFINuCdTf0AUHpclP0GD0f4CpShSNCTgc/76CJPdk63BoH0opYwpzz 8y0jrBq0LT6g== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2020 01:52:14 -0700 IronPort-SDR: iEFBK9hw43SNyYE55/qG1GyBCco/ur0BvGwY2RTz4cHM3tJcOd6sfeM9yd3g9AojAeW0S1+lph ri5MUuys8bRA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,440,1583222400"; d="scan'208";a="414132602" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by orsmga004.jf.intel.com with ESMTP; 27 May 2020 01:52:14 -0700 Date: Wed, 27 May 2020 01:52:14 -0700 From: Sean Christopherson To: Vitaly Kuznetsov Cc: "Kirill A. Shutemov" , 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: <20200527085214.GP31696@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> <20200527050350.GK31696@linux.intel.com> <87eer56abe.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eer56abe.fsf@vitty.brq.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 6E4A8100E6929 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Wed, May 27, 2020 at 10:39:33AM +0200, Vitaly Kuznetsov wrote: > Sean Christopherson writes: > > > 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. > > We have rdmsr_safe() for that! :-) MSR (and hypercall to that matter) > should have an associated CPUID feature bit of course. rdmsr_safe() won't fly in early boot, e.g. verify_cpu. It probably doesn't matter for late enabling, but it might save some headache if there's ever a handoff from vBIOS. > Yes, hypercall + CPUID would do but normally we treat CPUID data as > static and in this case we'll make it a dynamically flipping There are multiple examples of dynamic CPUID, e.g. MWAIT and OSPKE. > bit. Especially if we introduce 'KVM_HC_DISABLE_MEM_PROTECTED' later. > > > > >> 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. > > > > And maybe even help us to resolve 'reboot' problem. > > -- > Vitaly >