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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E6D81C433E0 for ; Wed, 3 Jun 2020 11:14:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A87AE2067B for ; Wed, 3 Jun 2020 11:14:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TBNU0htz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A87AE2067B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3C68780007; Wed, 3 Jun 2020 07:14:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 377D98E0006; Wed, 3 Jun 2020 07:14:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2666280007; Wed, 3 Jun 2020 07:14:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id 0B9148E0006 for ; Wed, 3 Jun 2020 07:14:21 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B5D1F180AD80F for ; Wed, 3 Jun 2020 11:14:20 +0000 (UTC) X-FDA: 76887641880.21.board04_7d2e3d51c0737 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 9D776180442C0 for ; Wed, 3 Jun 2020 11:14:20 +0000 (UTC) X-HE-Tag: board04_7d2e3d51c0737 X-Filterd-Recvd-Size: 6801 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 3 Jun 2020 11:14:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591182859; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=66+2fJmyMEeOm+RfdaX0dEV8FbowH6WPfR+JgsoWFaY=; b=TBNU0htzL4T+BmdndP5/nCKIe0+PWjr97ZMgRxt6V1D21MbVrRcG1l7LiCKVhX0O0WOJrv GyzU8OU5n6V4BeFbiY9sEpirA3Bkk3UjCNwwnQE2rbBaaIWBoBpXpxga7KLUH8ILOWULWz Ywtqn8vjmig3ub0t9obE2ml3aKTG0IY= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-20-0Bp4_2vON3Ch7M_Y5V3g0w-1; Wed, 03 Jun 2020 07:14:17 -0400 X-MC-Unique: 0Bp4_2vON3Ch7M_Y5V3g0w-1 Received: by mail-ej1-f69.google.com with SMTP id z20so624804ejf.23 for ; Wed, 03 Jun 2020 04:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=66+2fJmyMEeOm+RfdaX0dEV8FbowH6WPfR+JgsoWFaY=; b=j5GG1MqmNwBu1ZxNE6mAuHrtI2w+feXmSIwF+3kMX1+pHBBRe4ueV1MaaHz7kpzvC5 3kDPqDS2mZvWMr+MXb3s4Km55Sp92uSgWFFXc7zHw0Dm96s6zm7oG5WwTNzm3pe4jYoy E0fzntp5zFv0fOl64Sm3Em/D+4fNw/0bcVfv3aALhpEZVIAUWDC3m4awDlclt941rj8z OntyUZrUxUoPtboj6P+B3pKGS5qrrCmx0dZ/huJ7g5banwTLxXUR/U3pKpPpvHVj/GWX wsxwmMf0LGbnNnNbw7H8/V1qgxejQZb1dNWIuLhe8NzXAwlvKnsVzlJFqAbZHdH+XZEJ eTRg== X-Gm-Message-State: AOAM532rPMKQ7qInL6GWXGLt0aInS9d14Rfc3rdJXBAHakKp2ULxK2Om Txp0vWLkeJ+0VsXkzDMMC5jrXnaUS8XPSmX3taD8DFuW/BQPicZsTzMKqMioimEHKvM9STCss90 pGuYV4kYSzlw= X-Received: by 2002:a17:906:560b:: with SMTP id f11mr12470111ejq.11.1591182856267; Wed, 03 Jun 2020 04:14:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmmkDjbCjAIUFgF6xHVnWC41NZMGs2xGfwkhaV1dIKlp/faLOhnX0X4W/6u4Q/Xq0ZFu5mvQ== X-Received: by 2002:a17:906:560b:: with SMTP id f11mr12470075ejq.11.1591182856011; Wed, 03 Jun 2020 04:14:16 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id us3sm962679ejb.31.2020.06.03.04.14.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 04:14:15 -0700 (PDT) From: Vitaly Kuznetsov To: "Huang\, Kai" Cc: "kvm\@vger.kernel.org" , "wad\@chromium.org" , "Kleen\, Andi" , "luto\@kernel.org" , "aarcange\@redhat.com" , "keescook\@chromium.org" , "dave.hansen\@linux.intel.com" , "wanpengli\@tencent.com" , "kirill.shutemov\@linux.intel.com" , "linux-kernel\@vger.kernel.org" , "pbonzini\@redhat.com" , "linux-mm\@kvack.org" , "joro\@8bytes.org" , "peterz\@infradead.org" , "jmattson\@google.com" , "Edgecombe\, Rick P" , "rientjes\@google.com" , "x86\@kernel.org" , "kirill\@shutemov.name" , "Christopherson\, Sean J" Subject: Re: [RFC 02/16] x86/kvm: Introduce KVM memory protection feature In-Reply-To: <0cd53be8abede7e82a68c32b1d8b0e4ca6f24a05.camel@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> <0cd53be8abede7e82a68c32b1d8b0e4ca6f24a05.camel@intel.com> Date: Wed, 03 Jun 2020 13:14:13 +0200 Message-ID: <87r1uwflkq.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Queue-Id: 9D776180442C0 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: "Huang, Kai" writes: > On Wed, 2020-05-27 at 10:39 +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. >> >> Yes, hypercall + CPUID would do but normally we treat CPUID data as >> static and in this case we'll make it a dynamically flipping >> bit. Especially if we introduce 'KVM_HC_DISABLE_MEM_PROTECTED' later. > > Not sure why is KVM_HC_DISABLE_MEM_PROTECTED needed? > I didn't put much thought in it but we may need it to support 'kexec' case when no reboot is performed but we either need to pass the data about which regions are protected from old kernel to the new one or 'unprotect exerything'. -- Vitaly