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 39DADC6379F for ; Tue, 17 Jan 2023 17:27:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234252AbjAQR1Y (ORCPT ); Tue, 17 Jan 2023 12:27:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235083AbjAQRZm (ORCPT ); Tue, 17 Jan 2023 12:25:42 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E925449026 for ; Tue, 17 Jan 2023 09:25:21 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id z4-20020a17090a170400b00226d331390cso34731810pjd.5 for ; Tue, 17 Jan 2023 09:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=oPCKpcym2RW5d35rmFIPP7PcNPID9DHF3zaB9zUqfc0=; b=fcIljTThBG4xJap5TcGlXLzzw36TVvznNFdH4K5cV1wgP0TBEN+a0DD1GCYhRROsCO QvjnEf/w+v2arlNJbI9HWsv3aQkGE66ZYpTq2jVV7H8jTKB+jcivNkBG1DLGh2COfKTX pweZYAuWKUG+YbRSPiUyMiUsIhMoDelNa4TCm0Xonr0YcRslVr+wkYXPREIFWc5njYN5 hleDjpP/fD2PR+Pk217/hDlyN417xQoAuBfDpMCd7cMkK5+rXFZvrG6QdKzfXmWAaGuZ MtZaFsL+TjIMHfkIcKjhxx6/QR2rCC95vb8NVwOqOTD6jTRuiCKfm4a07+k8PrsQ0gnu +dNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oPCKpcym2RW5d35rmFIPP7PcNPID9DHF3zaB9zUqfc0=; b=e5dlbZPc4F6EKWzbkT2zCmGYqh7NqlwhbwoqElaIq9yNgE+qXvXG8Tz3kGxYodqUk9 DCOOz2/eJpmgk+JqDVFy5Dkmpp+20zUw15SDoB8ReeDo3KcbBZuEAfBZtWz8mqReuASy 5SI6WWMm9jDn5vZZpPw8vYiAwR0JJXiEMwVzlLFjCpvF1CjadiqhcT7C+n9WjZzlEIOz Kt9YOPwBpjExh9ay5zQBZqIlEw1qxvoojFcy65HooLXIvJs0JQEkCfAcbaAEgJjz87SE UJEGeaZIiunVITtLVUB7oj423nWGORBjJfJTQKHo8l3W1AI6MXf6Cj0yFINUvKdw3C+R TyFA== X-Gm-Message-State: AFqh2krAXBduYdlawBhNTJP5QHvZSwPZR2HoUVx6JLPwUJsS+zybXYbc 3W6zW9JHKXvVSbgM6RRFMEtHK4HPJir/yUvW X-Google-Smtp-Source: AMrXdXvUnfK+nwEzio3X173A3OOI+axnR8EWU2P/trlYbT/Eyg2+Qv0Pg0jRmQ5K8mkAb8pmdGJXpw== X-Received: by 2002:a05:6a20:8f02:b0:b8:c646:b0e2 with SMTP id b2-20020a056a208f0200b000b8c646b0e2mr385151pzk.3.1673976320986; Tue, 17 Jan 2023 09:25:20 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y3-20020a17090a390300b0022960d00017sm4505994pjb.22.2023.01.17.09.25.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 09:25:20 -0800 (PST) Date: Tue, 17 Jan 2023 17:25:16 +0000 From: Sean Christopherson To: Chao Peng Cc: Binbin Wu , 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 , 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: References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-3-chao.p.peng@linux.intel.com> <20230117133015.GE273037@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230117133015.GE273037@chaop.bj.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 17, 2023, Chao Peng wrote: > On Tue, Jan 17, 2023 at 11:21:10AM +0800, Binbin Wu wrote: > > > > On 12/2/2022 2:13 PM, Chao Peng wrote: > > > In confidential computing usages, whether a page is private or shared is > > > necessary information for KVM to perform operations like page fault > > > handling, page zapping etc. There are other potential use cases for > > > per-page memory attributes, e.g. to make memory read-only (or no-exec, > > > or exec-only, etc.) without having to modify memslots. > > > > > > Introduce two ioctls (advertised by KVM_CAP_MEMORY_ATTRIBUTES) to allow > > > userspace to operate on the per-page memory attributes. > > > - KVM_SET_MEMORY_ATTRIBUTES to set the per-page memory attributes to > > > a guest memory range. > > > - KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to return the KVM supported > > > memory attributes. > > > > > > KVM internally uses xarray to store the per-page memory attributes. > > > > > > Suggested-by: Sean Christopherson > > > Signed-off-by: Chao Peng > > > Link: https://lore.kernel.org/all/Y2WB48kD0J4VGynX@google.com/ > > > --- > > > Documentation/virt/kvm/api.rst | 63 ++++++++++++++++++++++++++++ > > > arch/x86/kvm/Kconfig | 1 + > > > include/linux/kvm_host.h | 3 ++ > > > include/uapi/linux/kvm.h | 17 ++++++++ > > > > Should the changes introduced in this file also need to be added in > > tools/include/uapi/linux/kvm.h ? > > Yes I think. I'm not sure how Paolo or others feel, but my preference is to never update KVM's uapi headers in tools/ in KVM's tree. Nothing KVM-related in tools/ actually relies on the headers being copied into tools/, e.g. KVM selftests pulls KVM's headers from the .../usr/include/ directory that's populated by `make headers_install`. Perf's tooling is what actually "needs" the headers to be copied into tools/, so my preference is to let the tools/perf maintainers deal with the headache of keeping everything up-to-date. > But I'm hesitate to include in this patch or not. I see many commits sync > kernel kvm.h to tools's copy. Looks that is done periodically and with a > 'pull' model.