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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 31F7CC27C50 for ; Tue, 4 Jun 2024 23:37:48 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=bWp/+fMg; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Vv6TP6xH8z3dK9 for ; Wed, 5 Jun 2024 09:37:45 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=bWp/+fMg; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::114a; helo=mail-yw1-x114a.google.com; envelope-from=3gqvfzgykdb0l73gc59hh9e7.5hfebgnqii5-67oeblml.hse34l.hk9@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Vv6Sb0VwRz3c3D for ; Wed, 5 Jun 2024 09:37:01 +1000 (AEST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-62ca03fc1ceso40677237b3.1 for ; Tue, 04 Jun 2024 16:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717544218; x=1718149018; darn=lists.ozlabs.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=p6cRhpzsCNepMdsrfgI93QBKDGHo0p9E5+86VMMwQfk=; b=bWp/+fMgJySedtKqF1D+TC3FfeJYNy0zD8kaIbZv/yR8fjok7r3iwzn3usTB+B8rEH wEzI9Nv0DvOIJGhGBDGlLmh8gv8mLz9t72D6k7A2sNzWVRH6+8dkhgL/VEq0lTRcRpzk yj3Gb//GjxwAtrEiNj6Pe4g+X8Sd9APp2U2MmpX/IuBDcXFfYyLRRpDzM9Q/jy7e/7Ca Wn3G8eUQUSOzxQAmv0A+eyPrJSSj/TEVsQx7UBJGrv9WKw5PGGNYhvZY+M4wr9fsT6sa f5dSVqva4IvPUeGMfkBQpiZDpmKmsHwM2Az1p5oBbdHFXAoI231xe25YoIosBCRWgQjH cm0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717544218; x=1718149018; h=content-transfer-encoding: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=p6cRhpzsCNepMdsrfgI93QBKDGHo0p9E5+86VMMwQfk=; b=CSzXlNc1I9j4okve+2tEsd06VfT8lxJt7AOcVMQbCvqvQrpV1W2atYd2cfR0tVKYPp hCzxjxJjdvakiFrQsDSK/SSNuIlgBIZFDzJ/NrI8eS8/p+xfZqG2p91xxZkDirsTlo/l 1uVwQD070NM4FbYoIRXuRs27AbnORg2spcmCi48/rEx1idliXgxvHitDvPFcM2vvTnhY 1HCLWZbw0QP7Dg5AExeiphXvPFo3BDuH+8l987fUpHxx5nIe293aI0YxDmIq0PH17Kaw hXAOBUU5it7UZmXIOs3t/6qUErFJHXalcsXTMrxWS4qvXCMRYSUInwJUj00Q7+f+JCKm pVGQ== X-Forwarded-Encrypted: i=1; AJvYcCVYHdTDeQSmFnQyxooOMe2MgF3H6TXfR2iHMVWWnoYggGpIlnnVoaYoi9pLEIA2dJCFkR8MwLrT/RVvMNtpOgpC1wA+x+P1DHoVr7luyw== X-Gm-Message-State: AOJu0Yy5Khle5Laq3JhZERWvZgOZ6k++8xVekot7E+5AK1xpAkQqGHPg W4aLY0KO8HjHmcQ6Tyl6S4YMt78qVbOIcgNCYlFZyvPbxuW+2DDkMN6MWZRsC+CZnL+cjZ7vSs+ Giw== X-Google-Smtp-Source: AGHT+IGvDf74cxgWq1gEKNpKx7itTcK7riRR46b0a169PbO8HQdl4CdVTPFkPhLbD8V/0e9PxPNrLdgSGrY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1142:b0:df7:9ac4:f1b2 with SMTP id 3f1490d57ef6-dfacac478ebmr240926276.5.1717544218030; Tue, 04 Jun 2024 16:36:58 -0700 (PDT) Date: Tue, 4 Jun 2024 16:36:56 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240529180510.2295118-1-jthoughton@google.com> <20240529180510.2295118-7-jthoughton@google.com> Message-ID: Subject: Re: [PATCH v4 6/7] KVM: arm64: Relax locking for kvm_test_age_gfn and kvm_age_gfn From: Sean Christopherson To: Oliver Upton Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: James Houghton , kvm@vger.kernel.org, linux-doc@vger.kernel.org, Catalin Marinas , Atish Patra , linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, Raghavendra Rao Ananta , linux-riscv@lists.infradead.org, Shuah Khan , Yu Zhao , Jonathan Corbet , Anup Patel , Huacai Chen , David Rientjes , Zenghui Yu , Axel Rasmussen , linux-mips@vger.kernel.org, Albert Ou , Ryan Roberts , Will Deacon , Suzuki K Poulose , Shaoqin Huang , Nicholas Piggin , Bibo Mao , loongarch@lists.linux.dev, Paul Walmsley , David Matlack , Palmer Dabbelt , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, Ankit Agrawal , James Morse , kvm-riscv@lists.infradead.org, Marc Zyngier , Paolo Bonzini , Andrew Morton , Tianrui Zhao , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Jun 04, 2024, Oliver Upton wrote: > On Tue, Jun 04, 2024 at 03:20:20PM -0700, James Houghton wrote: > > On Fri, May 31, 2024 at 12:18=E2=80=AFPM Oliver Upton wrote: > > > > > > On Fri, May 31, 2024 at 12:11:33PM -0700, Oliver Upton wrote: > > > > On Wed, May 29, 2024 at 06:05:09PM +0000, James Houghton wrote: > > > Oh, and the WARN_ON() in kvm_pgtable_stage2_test_clear_young() is bog= us > > > now. Maybe demote it to: > > > > > > r =3D kvm_pgtable_walk(...); > > > WARN_ON_ONCE(r && r !=3D -EAGAIN); > >=20 > > Oh, indeed, thank you. Just to make sure -- does it make sense to > > retry the cmpxchg if it fails? For example, the way I have it now for > > x86[1], we retry the cmpxchg if the spte is still a leaf, otherwise we > > move on to the next one having done nothing. Does something like that > > make sense for arm64? >=20 > At least for arm64 I do not see a need for retry. The only possible > races are: >=20 > - A stage-2 fault handler establishing / adjusting the mapping for the > GFN. If the guest is directly accessing the GFN in question, what's > the point of wiping out AF? >=20 > Even when returning -EAGAIN we've already primed stage2_age_data::youn= g, > so we report the correct state back to the primary MMU. >=20 > - Another kvm_age_gfn() trying to age the same GFN. I haven't even > looked to see if this is possible from the primary MMU POV, but in > theory one of the calls will win the race and clear AF. >=20 > Given Yu's concerns about making pending writers wait, we should take > every opportunity to bail on the walk. +1. The x86 path that retries is, for all intents and purposes, limited to= Intel CPUs that don't support EPT A/D bits, i.e. to pre-HSW CPUs. I wouldn't mak= e any decisions based on that code.