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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C98AC3DA7A for ; Tue, 3 Jan 2023 01:44:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233786AbjACBoU (ORCPT ); Mon, 2 Jan 2023 20:44:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230486AbjACBoQ (ORCPT ); Mon, 2 Jan 2023 20:44:16 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B489C627F; Mon, 2 Jan 2023 17:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1672710255; x=1704246255; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=kIuNdU/0BTpRBUyYlNa5j3GUvL63FAbv1n39zRBT40o=; b=bQJP3fqSOKbx7aiPvOdVujVKhkkpfgO0rX6OMY/pB+Rg8+oOSoc+zoE3 3UW1DCJMBdFxQ0XPfZXhdpna+YPpDN8uylotIK5eIZ4oTOidOFpGvE9Uc NlzaKSWt1/HxzRCxgaRaLIa5IyuGckiJHbJPsV/BInoGW+IT29cA6xcWr /YvnY14++Qh/vir1z6JwzBj72yvlcLcwvHwmEOYx0Ub2L4hGzJbL/D5CA KkQDAr5ulmG87HqiuxCRPNIwFFCPoWBeYJXI/+LOD6IxMIIM1WIif4tw6 yPFl/iTC+td9ChegbGzp65eYOttN+O9imJzkjryRxM1TT6CzKOPGlNdh0 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10578"; a="407822398" X-IronPort-AV: E=Sophos;i="5.96,295,1665471600"; d="scan'208";a="407822398" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jan 2023 17:44:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10578"; a="828701041" X-IronPort-AV: E=Sophos;i="5.96,295,1665471600"; d="scan'208";a="828701041" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga005.jf.intel.com with ESMTP; 02 Jan 2023 17:44:01 -0800 Date: Tue, 3 Jan 2023 09:39:48 +0800 From: Chao Peng To: Chenyi Qiang Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com Subject: Re: [PATCH v10 2/9] KVM: Introduce per-page memory attributes Message-ID: <20230103013948.GA2178318@chaop.bj.intel.com> Reply-To: Chao Peng References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-3-chao.p.peng@linux.intel.com> <1c9bbaa5-eea3-351e-d6a0-cfbc32115c82@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c9bbaa5-eea3-351e-d6a0-cfbc32115c82@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 28, 2022 at 04:28:01PM +0800, Chenyi Qiang wrote: ... > > +static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm, > > + struct kvm_memory_attributes *attrs) > > +{ > > + gfn_t start, end; > > + unsigned long i; > > + void *entry; > > + u64 supported_attrs = kvm_supported_mem_attributes(kvm); > > + > > + /* flags is currently not used. */ > > + if (attrs->flags) > > + return -EINVAL; > > + if (attrs->attributes & ~supported_attrs) > > + return -EINVAL; > > + if (attrs->size == 0 || attrs->address + attrs->size < attrs->address) > > + return -EINVAL; > > + if (!PAGE_ALIGNED(attrs->address) || !PAGE_ALIGNED(attrs->size)) > > + return -EINVAL; > > + > > + start = attrs->address >> PAGE_SHIFT; > > + end = (attrs->address + attrs->size - 1 + PAGE_SIZE) >> PAGE_SHIFT; > > + > > + entry = attrs->attributes ? xa_mk_value(attrs->attributes) : NULL; > > + > > Because guest memory defaults to private, and now this patch stores the > attributes with KVM_MEMORY_ATTRIBUTE_PRIVATE instead of _SHARED, it > would bring more KVM_EXIT_MEMORY_FAULT exits at the beginning of boot > time. Maybe it can be optimized somehow in other places? e.g. set mem > attr in advance. KVM defaults to 'shared' because this ioctl can also be potentially used by normal VMs and 'shared' sounds a value meaningful for both normal VMs and confidential VMs. As for more KVM_EXIT_MEMORY_FAULT exits during the booting time, yes, setting all memory to 'private' for confidential VMs through this ioctl in userspace before guest launch is an approach for KVM userspace to 'override' the KVM default and reduce the number of implicit conversions. Thanks, Chao > > > + mutex_lock(&kvm->lock); > > + for (i = start; i < end; i++) > > + if (xa_err(xa_store(&kvm->mem_attr_array, i, entry, > > + GFP_KERNEL_ACCOUNT))) > > + break; > > + mutex_unlock(&kvm->lock); > > + > > + attrs->address = i << PAGE_SHIFT; > > + attrs->size = (end - i) << PAGE_SHIFT; > > + > > + return 0; > > +} > > +#endif /* CONFIG_HAVE_KVM_MEMORY_ATTRIBUTES */ > > + > > struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn) > > { > > return __gfn_to_memslot(kvm_memslots(kvm), gfn);