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 C51BAC433F5 for ; Wed, 5 Oct 2022 22:06:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229731AbiJEWGK (ORCPT ); Wed, 5 Oct 2022 18:06:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229495AbiJEWGH (ORCPT ); Wed, 5 Oct 2022 18:06:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79CDF558FE; Wed, 5 Oct 2022 15:06:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 249DAB81F47; Wed, 5 Oct 2022 22:06:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62B71C433C1; Wed, 5 Oct 2022 22:06:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665007561; bh=FZGWwvWcMPwpxhSCd2CpWK7kBaSufMBeg2cE71W2BOY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kdwp8mBwA4DxgGXMH8RNJfp6niTBmA+A9hvnQifpjbB/DwhTINU4J92nzxhIihcHU 3HR6iqLo8aUthnB8oK7k1r0em3qa9j73goc4WNh/TYrAcrV/j62fbfBQtjg7XtfHWo qCO/KBvOtXmtDmsgBesgS10c3dnJ6gGWsOHMnVypAyumop+29fsWTApZgz7r0wS7/X 6z0++64qq/oG9Y0sPvjb+ba5dE+/RUzUVbhDILKLMRTsU88wTBvOOBUUs6KszlPfrC f5joADFiEGvpbEDfO8T7W7oqNqs7Hg84FMWv/ZXI4zp9NyZbNLqY+wby7ze6dNi6ti 3a8z6u/Jb6R5g== Date: Thu, 6 Oct 2022 01:05:57 +0300 From: Jarkko Sakkinen To: Chao Peng Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@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 , 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 , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v8 2/8] KVM: Extend the memslot to support fd-based private memory Message-ID: References: <20220915142913.2213336-1-chao.p.peng@linux.intel.com> <20220915142913.2213336-3-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 05, 2022 at 04:04:05PM +0300, Jarkko Sakkinen wrote: > On Thu, Sep 15, 2022 at 10:29:07PM +0800, Chao Peng wrote: > > In memory encryption usage, guest memory may be encrypted with special > > key and can be accessed only by the VM itself. We call such memory > > private memory. It's valueless and sometimes can cause problem to allow > > userspace to access guest private memory. This patch extends the KVM > > memslot definition so that guest private memory can be provided though > > an inaccessible_notifier enlightened file descriptor (fd), without being > > mmaped into userspace. > > > > This new extension, indicated by the new flag KVM_MEM_PRIVATE, adds two > > additional KVM memslot fields private_fd/private_offset to allow > > userspace to specify that guest private memory provided from the > > private_fd and guest_phys_addr mapped at the private_offset of the > > private_fd, spanning a range of memory_size. > > > > The extended memslot can still have the userspace_addr(hva). When use, a > > single memslot can maintain both private memory through private > > fd(private_fd/private_offset) and shared memory through > > hva(userspace_addr). Whether the private or shared part is visible to > > guest is maintained by other KVM code. > > > > Since there is no userspace mapping for private fd so we cannot > > get_user_pages() to get the pfn in KVM, instead we add a new > > inaccessible_notifier in the internal memslot structure and rely on it > > to get pfn by interacting with the memory file systems. > > > > Together with the change, a new config HAVE_KVM_PRIVATE_MEM is added and > > right now it is selected on X86_64 for Intel TDX usage. > > > > To make code maintenance easy, internally we use a binary compatible > > alias struct kvm_user_mem_region to handle both the normal and the > > '_ext' variants. > > > > Co-developed-by: Yu Zhang > > Signed-off-by: Yu Zhang > > Signed-off-by: Chao Peng > > What if userspace_addr would contain address of an extension structure, > if the flag is set, instead of shared address? I.e. interpret that field > differently (could be turned into union too ofc). > > That idea could be at least re-used, if there's ever any new KVM_MEM_* > flags that would need an extension. > > E.g. have struct kvm_userspace_memory_private, which contains shared > address, fd and the offset. Or add a new ioctl number instead of messing with the existing parameter structure, e.g. KVM_SET_USER_MEMORY_REGION_PRIVATE. With this alternative and the current approach in the patch, it would be better just to redefine the struct fields that are common. It actually would reduce redundancy because then there is no need to create that somewhat confusing kernel version of the same struct, right? You don't save any redundancy with this "embedded struct" approach. BR, Jarkko