Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp5519rwo; Fri, 21 Jul 2023 07:51:47 -0700 (PDT) X-Google-Smtp-Source: APBJJlEm2f7lm+GogAD4BaCsuW1MySXvHPkRDIAqmMNJdfkHxFgtERmLFocN/xEpbJHBlhpHX6bS X-Received: by 2002:a05:6a20:7494:b0:136:42c8:693c with SMTP id p20-20020a056a20749400b0013642c8693cmr1896160pzd.6.1689951106677; Fri, 21 Jul 2023 07:51:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689951106; cv=none; d=google.com; s=arc-20160816; b=M7xKuGti9OQPu7/Cvh7LdNnED3u5uwrN47zwpNWmieBwNoUNcLOEzyJQajpYZjCPAr mUXk7sjOiC6fnIPM4lAZ1i8/Lpv/ApnfbmKHvGl8GJjIfB7dx6bBxf6Dx5hZkxzl7RPc AipBeJ4zD58cVv3Dg840E7pOxNECipAbu81AHataL8GHMoQ5whNe3CwlM9lq11iYC7Xw +YwA31OKaj3h7wETtMaiV0Kwct3lgi9EWdxt00TrEN9L5B1TUkgidSvb1F8yLrG5yhoe DwvQwVe7ZLtHOa/5qXzcsfZFJJ+JE01Nmg8Q1hf8o7FRPkzmEeFEeyoyeT3VBZT+sY4U 4f8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=qsOblVN0R0vt/pe3dNZWP7QQiaTx7X4bgufFrqaLpho=; fh=GpCfOgtqXfT8y/li0MBFEOLKkwLHT5slJrRdVJSOoHE=; b=LQHGU52XquTKCdih0AHat2CjIHr++aoEmPEil/4/rt4KiHK4CFM+gDPcbbaPn5mqYD k0WcLgC4E12adv5tEo4jwAfZPE3I9lDsgl8sBIeW8rPcEt1573HPxnCqF1heLzPtDyxp RQcNI/ObTmfBInXNPygkIf4x28ghHFdT5Mu7LG/p08kZ35CZktRI4w7n27bj+L/M8loi fjwI+MP7aFn7UvT4LuXcXOpp/7DPoDe2UB4tE+rf8iomRV2B0f+YtUkNryC3qEDtn3Ph un0qbFxO6F4VBBuQv266EOJRizoQHBIhQdNgXJRcAv6YGM3Dn/JFgjnYmMnAjLGuIrra L80w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b="cGBHW/6K"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 189-20020a6300c6000000b0055c7eb53d7fsi3102487pga.584.2023.07.21.07.51.34; Fri, 21 Jul 2023 07:51:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b="cGBHW/6K"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230475AbjGUO0D (ORCPT + 99 others); Fri, 21 Jul 2023 10:26:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230219AbjGUO0B (ORCPT ); Fri, 21 Jul 2023 10:26:01 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A84B01BD for ; Fri, 21 Jul 2023 07:26:00 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-569e7aec37bso20293857b3.2 for ; Fri, 21 Jul 2023 07:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689949560; x=1690554360; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=qsOblVN0R0vt/pe3dNZWP7QQiaTx7X4bgufFrqaLpho=; b=cGBHW/6K1sW6ejc8bX15/z0rQMq0wpeeceuX8mY+GNE8GIy9t1+zTMzpJ9tfj5nofb ognBRrmq4MHOycdxBwA5oUh3s92ngcSXiMyYAw8dbCbR4hwgS7SkVmsNmHVnxCii7UtH eDlIzCF+QNfGeyJMQ6G5q0Sgf8Cry2iVYlWNs2RXUnOhOkH/QfoeRTTeNciF8K9Ft0x4 /tcc15TTPjIADvjUoRNLSjgR87jS23/3RFVkZqjPFQ4aurgk+AQnDOJbUlFHSFn+fjqX WVGX6Pw6cCmfNNxOLlGW3i/zMiuPKL702bffjmRHgrAL/GaPa/BBVMAtrTIb8Lo3Qfa2 JCcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689949560; x=1690554360; 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=qsOblVN0R0vt/pe3dNZWP7QQiaTx7X4bgufFrqaLpho=; b=SqnZSYKxYteWMx+JKukPdRbAuU7GzGFb6vI0NnYYPoO2XrZ3QAFZnlq7FPCk2KUIdT TbhvbOeWoZGai2G04I7UCs+w9oCG4u3BTpqm/kfCsdnFQqyLeicBoaBmjLpe5JDxyaSy zi286PBIkYcDY0Ntld6H3+LX8KWHulT6DG1555X+4R/JUAbAUgVux7SNeyLFcKZWwXTa hKNMtjsQqrRuXJfLf0puHnDfC2Wfbc8dGxvNqFxwZhDeBsIsaCbUfDHcFcc9qSd0fqVi FHPtQfkYGnBhCWL20syjR0NUmiD5oKXiuzNyfN+2fmWMifwY6vyi1hzsfkKzWmEcvtMJ vJ4w== X-Gm-Message-State: ABy/qLYk0HFi3dEDeNJe0Fm5buxL0DimzN9d6PqO3zaakln5rty3JzLY xjSy24oizRCfOgmAzHW1kORnDH+JJxU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:e74f:0:b0:ce8:e6f:440c with SMTP id e76-20020a25e74f000000b00ce80e6f440cmr11741ybh.6.1689949559993; Fri, 21 Jul 2023 07:25:59 -0700 (PDT) Date: Fri, 21 Jul 2023 07:25:58 -0700 In-Reply-To: <21e488b6ced77c08d9e6718fcf57e100af409c64.1689893403.git.isaku.yamahata@intel.com> Mime-Version: 1.0 References: <21e488b6ced77c08d9e6718fcf57e100af409c64.1689893403.git.isaku.yamahata@intel.com> Message-ID: Subject: Re: [RFC PATCH v4 07/10] KVM: x86: Add gmem hook for initializing private memory From: Sean Christopherson To: isaku.yamahata@intel.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Michael Roth , Paolo Bonzini , erdemaktas@google.com, Sagi Shahar , David Matlack , Kai Huang , Zhi Wang , chen.bo@intel.com, linux-coco@lists.linux.dev, Chao Peng , Ackerley Tng , Vishal Annapurve , Yuan Yao Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 20, 2023, isaku.yamahata@intel.com wrote: > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index a73ddb43a2cf..35bb14363828 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -4352,6 +4352,7 @@ static int kvm_faultin_pfn_private(struct kvm_vcpu *vcpu, > struct kvm_page_fault *fault) > { > int max_order, r; > + u8 max_level; > > if (!kvm_slot_can_be_private(fault->slot)) > return kvm_do_memory_fault_exit(vcpu, fault); > @@ -4361,8 +4362,15 @@ static int kvm_faultin_pfn_private(struct kvm_vcpu *vcpu, > if (r) > return r; > > - fault->max_level = min(kvm_max_level_for_order(max_order), > - fault->max_level); > + max_level = kvm_max_level_for_order(max_order); > + r = static_call(kvm_x86_gmem_prepare)(vcpu->kvm, fault->slot, fault->pfn, > + fault->gfn, &max_level); I think KVM should hook gmem itself, i.e. convert pages to private when they're allocated, and then back to shared when they're freed. I don't like having asymmetric APIs (convert on fault instead of allocate, but then convert back on free instead of on zap), and hooking the page fault path also violates the approach of tying the RMP/HKID to the physical allocation. Practically speaking, hooking the fault path will result in undesirable behavior. Just because KVM *maps* at 4KiB granularity doesn't mean the RMP must be assigned at 4KiB granularity, e.g. if userspace chooses to *not* PUNCH_HOLE when the guest shares a single 4KiB page in a 2MiB chunk. Dirty logging is another case where the RMP can stay at 2MiB. Or as a very silly example, imagine userspace pulls a stupid and covers a single 2MiB chunk of gmem with 512 memslots. That likely means KVM will need an additional hook to clamp the max_level at the RMP, but that shouldn't be a big deal, e.g. if we convert on allocation, then KVM should be able to blindly do the conversion because it would be a kernel bug if the page is already assigned to an ASID in the RMP, i.e. the additional hook shouldn't incur an extra RMP lookup.