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 949FEC742A7 for ; Tue, 7 Mar 2023 20:27:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229651AbjCGU1h (ORCPT ); Tue, 7 Mar 2023 15:27:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230007AbjCGU1c (ORCPT ); Tue, 7 Mar 2023 15:27:32 -0500 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0494521E6 for ; Tue, 7 Mar 2023 12:27:30 -0800 (PST) Received: by mail-pj1-x1049.google.com with SMTP id m9-20020a17090a7f8900b0023769205928so8599127pjl.6 for ; Tue, 07 Mar 2023 12:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678220850; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=WGcASroMdccxdn62Jjtjh8PVnJGDXhBcjr99ONuCvY4=; b=OwwLfDPKljzAkPvlj0S/FrolNQFkMYhVCSYaPZA6BhlyFeubRSg3vonk6akM+nwgAx dcS6vYx/LWgfF4nSPN+n5wRbJl1+oX04X/RQuea86YN+QKQuGEhXA8GHTKbpJNljgVbg 1tgLB7KavCS6Q8io76xaUiHKm29QSamSGbG7VBUDlQZNg7fOcC8uJ1SLfFlvvf38+NHp H0+zdtAOsLWl91QdOI5eJY+EmcNzqsXqCw01IvZ9IrObznTsFWqkSsLtumj8X2Gb549e mgTJkRz7STcC9OGGE966xqlp75dxFmI9JO9DcpLgaboo61ZXNHLGYkcot+ahXB1p5gKf Im0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678220850; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WGcASroMdccxdn62Jjtjh8PVnJGDXhBcjr99ONuCvY4=; b=PtyqODq0FADO4ryIRCOHJJ2TCG0HdUOtE1fdc/v1DjetTGANdfBPhf3MQSrxjbU4MM 6Q52JocQO6kYGZ1QB2sYmUlA/ATbEf/5raiYmKOKE6FXytfcuCJB6/skXWIjGnHyQ6Av 5zgoqdFEl1arz9NfGDt6EMtfcu58Fe1HAMvUQ2CbtncU5q+ht7W/Wp7q2Lhj4T4aNFMl qAaenGcAX9nHMAZ+acOzu5p0ukx9tCCgLEcen9/nG1ffExetpD3Hy+cnpasVAxw0hIt1 JPmNohi7tof9S5BNf+AW/uKyEGou6w/TM2M6DoGJgxEXSAjxW1lijp5bhFrXG3SHlrJO DoiQ== X-Gm-Message-State: AO0yUKWYb0TCBwTRRotwFB9oyOXWEtCgnw7EUgq6a6I8Sr7Sy2kSwoo9 2kr7V9mZK4iL6wYpWEOe4i8+4DRy1Hw= X-Google-Smtp-Source: AK7set9n+PBGh5X4bHcHssSmlZaRESH4dUDPeHJTAkKKGP+YbNHu8+uM5MNsGFpRsbe7uC0L5WQKdFmMJ3c= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:2948:0:b0:503:7bcd:9806 with SMTP id bu8-20020a632948000000b005037bcd9806mr5442294pgb.4.1678220850029; Tue, 07 Mar 2023 12:27:30 -0800 (PST) Date: Tue, 7 Mar 2023 12:27:28 -0800 In-Reply-To: Mime-Version: 1.0 References: <20221202061347.1070246-10-chao.p.peng@linux.intel.com> Message-ID: Subject: Re: [PATCH v10 9/9] KVM: Enable and expose KVM_MEM_PRIVATE From: Sean Christopherson To: Ackerley Tng Cc: Chao Peng , 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, pbonzini@redhat.com, corbet@lwn.net, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, arnd@arndb.de, naoya.horiguchi@nec.com, linmiaohe@huawei.com, x86@kernel.org, hpa@zytor.com, hughd@google.com, jlayton@kernel.org, bfields@fieldses.org, akpm@linux-foundation.org, shuah@kernel.org, rppt@kernel.org, steven.price@arm.com, mail@maciej.szmigiero.name, vbabka@suse.cz, vannapurve@google.com, yu.c.zhang@linux.intel.com, kirill.shutemov@linux.intel.com, 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, qperret@google.com, tabba@google.com, michael.roth@amd.com, mhocko@suse.com, wei.w.wang@intel.com Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Please trim your replies so that readers don't need to scan through a hundred or so lines of quotes just to confirm there's nothing there. On Tue, Mar 07, 2023, Ackerley Tng wrote: > Chao Peng writes: > > > Register/unregister private memslot to fd-based memory backing store > > restrictedmem and implement the callbacks for restrictedmem_notifier: > > - invalidate_start()/invalidate_end() to zap the existing memory > > mappings in the KVM page table. > > - error() to request KVM_REQ_MEMORY_MCE and later exit to userspace > > with KVM_EXIT_SHUTDOWN. > > > Expose KVM_MEM_PRIVATE for memslot and KVM_MEMORY_ATTRIBUTE_PRIVATE for > > KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to userspace but either are > > controlled by kvm_arch_has_private_mem() which should be rewritten by > > architecture code. > > Could we perhaps rename KVM_MEM_PRIVATE to KVM_MEM_PROTECTED, to be in > line with KVM_X86_PROTECTED_VM? > > I feel that a memslot that has the KVM_MEM_PRIVATE flag need not always > be private; It can sometimes be providing memory that is shared and > also accessible from the host. > > KVM_MEMORY_ATTRIBUTE_PRIVATE is fine as-is because this flag is set when > the guest memory is meant to be backed by private memory. > > KVM_MEMORY_EXIT_FLAG_PRIVATE is also okay because the flag is used to > indicate when the memory error is caused by a private access (as opposed > to a shared access). > > kvm_slot_can_be_private() could perhaps be renamed kvm_is_protected_slot()? No to this suggestion. I agree that KVM_MEM_PRIVATE is a bad name, but kvm_is_protected_slot() is just as wrong. The _only_ thing that the flag controls is whether whether or not the memslot has an fd that is bound to restricted memory. The memslot itself is not protected in any way, and if the entire memslot is mapped shared, then the data backed by the memslot isn't protected either. What about KVM_MEM_CAN_BE_PRIVATE? KVM_MEM_PRIVATIZABLE is more succinct, but AFAICT that's a made up word, and IMO is unnecessarily fancy.