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 2A64FC54EBD for ; Fri, 13 Jan 2023 15:58:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230357AbjAMP6U (ORCPT ); Fri, 13 Jan 2023 10:58:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230181AbjAMP5h (ORCPT ); Fri, 13 Jan 2023 10:57:37 -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 57C2F90E74 for ; Fri, 13 Jan 2023 07:49:04 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id o13so19306188pjg.2 for ; Fri, 13 Jan 2023 07:49:04 -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=wobIjMJNqTwtr3bYoELqDsKPAwD1PC9Q+itWmni1C6o=; b=b63RB6SUcCzsN6y8LRPVghJm6iLrFxEo37MywBuf7UMlj+FVwXhZZe4YLNQobeby9f 5Y7aa0MQGskyI2wvFHZz+jDqS363pC0Dz1i7oI/i6JDA6Xndz8H2Uyj6ctnHzV51E6/E w792bLZupviwtara97i1v6aHHvJ6p1tQzOr0T7doUpDitcCzKuM5r010rVTnPFIm3Bog RLbnXBcBp5mJBlujcwZJ1eZjCw7yBPrDxzjHsG8vRZXjN1VQLLh9sN8DhDoY0Ki7pAkB 2wQNZMUUctFpcWq/t8PpsJAki9xOcJ8zX1OD7H8Ltkbbcch0m4LNTv2NTDyZ6IZqe46O RhDQ== 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=wobIjMJNqTwtr3bYoELqDsKPAwD1PC9Q+itWmni1C6o=; b=fZhK0yoo0/DJo1G5JXFx7LVbq4BrgVE0TB3AAwXn+nN3IyDNz0KA+PmUDCUe9F9Vzr c6ye4WPwmKG427qRAslve48ccKY6f8pIpXqlb7fHGk8SCfls3g0etuZG1q/Bp1BdaOQk IBWUmavuBvwmHrVhoDak/sbwfHja0bQvLBWQnDmg6sdAanQM30iRY/CBLHIxLh0ps0tF pPv0eL5FdcAeSrIF1Y3tMjWZghSGGbiPcI+dT3+OmgQau5eQ3t4sj8pzYhDZ8Tbtloe0 iIypctF6YDDlTwCSWi4ciQKFQhHiAJXXdre8KCa+EVsTT+5bRetyLQaAqM+dULarrUiR gDBg== X-Gm-Message-State: AFqh2krqTBET9kZG5kCFXs+CGHTjoQ/wT3xtuwmwABcVFGAqgJunZw9B tRcF6aikyngK9IfJyAnVTUdPHQ== X-Google-Smtp-Source: AMrXdXsEAKrdgDrfSletqAhmR5qRLbIJ5zZEClWrVw8g6qy+aLPjc/GLLtqeuK1KgkeyLfP8BgaTBA== X-Received: by 2002:a17:90a:fd12:b0:226:5758:a57f with SMTP id cv18-20020a17090afd1200b002265758a57fmr1478484pjb.2.1673624943743; Fri, 13 Jan 2023 07:49:03 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id nv7-20020a17090b1b4700b00212cf2fe8c3sm2732462pjb.1.2023.01.13.07.49.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jan 2023 07:49:03 -0800 (PST) Date: Fri, 13 Jan 2023 15:48:59 +0000 From: Sean Christopherson To: Borislav Petkov Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, jarkko@kernel.org, ashish.kalra@amd.com, harald@profian.com Subject: Re: [PATCH RFC v7 04/64] KVM: x86: Add 'fault_is_private' x86 op Message-ID: References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-5-michael.roth@amd.com> <20230105024256.ptujtjgzcdmpakoa@amd.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 Fri, Jan 13, 2023, Borislav Petkov wrote: > On Wed, Jan 04, 2023 at 08:42:56PM -0600, Michael Roth wrote: > > Obviously I need to add some proper documentation for this, but a 1 > > return basically means 'private_fault' pass-by-ref arg has been set > > with the appropriate value, whereas 0 means "there's no platform-specific > > handling for this, so if you have some generic way to determine this > > then use that instead". > > Still binary, tho, and can be bool, right? > > I.e., you can just as well do: > > if (static_call(kvm_x86_fault_is_private)(kvm, gpa, err, &private_fault)) > goto out; > > at the call site. Ya. Don't spend too much time trying to make this look super pretty though, there are subtle bugs inherited from the base UPM series that need to be sorted out and will impact this code. E.g. invoking kvm_mem_is_private() outside of the protection of mmu_invalidate_seq means changes to the attributes may not be reflected in the page tables. I'm also hoping we can avoid a callback entirely, though that may prove to be more pain than gain. I'm poking at the UPM and testing series right now, will circle back to this and TDX in a few weeks to see if there's a sane way to communicate shared vs. private without having to resort to a callback, and without having races between page faults, KVM_SET_MEMORY_ATTRIBUTES, and KVM_SET_USER_MEMORY_REGION2. > > This is mainly to handle CONFIG_HAVE_KVM_PRIVATE_MEM_TESTING, which > > just parrots whatever kvm_mem_is_private() returns to support running > > KVM selftests without needed hardware/platform support. If we don't > > take care to skip this check where the above fault_is_private() hook > > returns 1, then it ends up breaking SNP in cases where the kernel has > > been compiled with CONFIG_HAVE_KVM_PRIVATE_MEM_TESTING, since SNP > > relies on the page fault flags to make this determination, not > > kvm_mem_is_private(), which normally only tracks the memory attributes > > set by userspace via KVM_SET_MEMORY_ATTRIBUTES ioctl. > > Some of that explanation belongs into the commit message, which is a bit > lacking... I'll circle back to this too when I give this series (and TDX) a proper look, there's got too be a better way to handle this.