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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61291C636D6 for ; Thu, 23 Feb 2023 18:35:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA7AB6B0071; Thu, 23 Feb 2023 13:35:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B57686B0072; Thu, 23 Feb 2023 13:35:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1F036B0073; Thu, 23 Feb 2023 13:35:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8FE796B0071 for ; Thu, 23 Feb 2023 13:35:12 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6164F40BE0 for ; Thu, 23 Feb 2023 18:35:12 +0000 (UTC) X-FDA: 80499408864.19.A735D80 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf07.hostedemail.com (Postfix) with ESMTP id 87A9540005 for ; Thu, 23 Feb 2023 18:35:10 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jCj+dZoF; spf=pass (imf07.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677177310; a=rsa-sha256; cv=none; b=4yVKNxF6/NP66sy5PM1/w+R4xtcCG8MWdmUnedGoJkPl80b8ZZKxn50nBlNHLtVbHGS4wj RIKWzpBEWIN/k4thL/ped/aDoPuzV/XK/P47QH4ScSyRftXhbuLFnhu5hnPlP1TwqvjsNY WTc1pKQhZMFmF7RpUYhuCHwhdE4z12Y= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jCj+dZoF; spf=pass (imf07.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677177310; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R3aoaYb7nna45J2CiXmr0/OoCloNPGdL3kFyB1h4mtg=; b=qTA8TzlaUwcSL7DtROQGOElodI/QQwfW5Ewczen8xbED+WOMTfUZIQ2kvdsMFw2LonOga+ +2toZoJdS5FmV1lJ/Es2svMW9agKnwJ4b38kKSwFPcGrb0mKJvED+3+XTYCZrP11HpXzn4 3STKOBc1DIQBZqcL1C5fbXeQdPRKNk8= Received: by mail-vs1-f54.google.com with SMTP id s1so680054vsk.5 for ; Thu, 23 Feb 2023 10:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=R3aoaYb7nna45J2CiXmr0/OoCloNPGdL3kFyB1h4mtg=; b=jCj+dZoFxxzUaMPmvj5JpARz5KC7OAzmfEjBubRdgSgpZo0gPgbIIaMDk8TdKd6ac2 1u/B51AGOkz6IDZyF96vCHj9MWL4W8T8cCEfO1KDEv652fn8V5t294GBY+/Y9lJyetLN GAnxFpn2GsWeExejnqMX0i/qSBTWbgzLOY47ucp3r/0Q7IWIyGfs+oyPY6FmIEHthFxp x1V6a3CHzQXzc/AiUlVpspoHDTQ52AKGsA7RaEhRwMTWU5QbHFFJAg1qM6/m/E8iGAA4 zRRqE9AWRBrMW/CVP69peHcgoVq+PjLM4Q2whQa/QhbAIhXI5S9sJDYuZ0HNey8baXK5 PyjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R3aoaYb7nna45J2CiXmr0/OoCloNPGdL3kFyB1h4mtg=; b=r3HYfiuTXxdFrhawNKhR51t4cSHCwAhVUCdpzXtruJtWO4l2L1KVLl8r6VXlEZZ/uL 5WKSTC1TYq2Ih55qfasvaD6cZsO+DUEJl2z62Rk/oo0rxoJlje5SjJY9II6nE5uB3Z/M PQJqkHOmSAn9tRj0Fd0s5dZpSY2c0tcoEIKu6bSfh3RG9qkiCXyC8x2reray6l/TJCwN 4KeZWvpagbo6A6qK1KN2ka24QNff3SEEF8YtgawZ1+qf6EOnB5U/j5w3CwsampaSAgDk 5gsunGMeTK+nGIrdd0PK3ovM4r6h8LwtMr8BY1qITJFFkBoiClZGX9xyksHf2NzuMf6H +fGg== X-Gm-Message-State: AO0yUKXhyMiPARhSqN7cSeOzlm43x9M4boLgzRhvQ1ePtlZBCFNjCNXz krsPRq+1Kz9i1iOo2rhqLgO82yQONWJ44EzJ0em6+g== X-Google-Smtp-Source: AK7set8MziVNDnEwhirxCtSzQkzlR2xXTlIFkFvt+M2EKaxLcFqsJW8+RDdsr+GQsS2XXD8mHYrFd1HoPptf+lvr4nU= X-Received: by 2002:a67:fdc8:0:b0:402:9ba2:bc62 with SMTP id l8-20020a67fdc8000000b004029ba2bc62mr510076vsq.6.1677177309518; Thu, 23 Feb 2023 10:35:09 -0800 (PST) MIME-Version: 1.0 References: <20230217041230.2417228-1-yuzhao@google.com> <20230217041230.2417228-3-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Thu, 23 Feb 2023 11:34:31 -0700 Message-ID: Subject: Re: [PATCH mm-unstable v1 2/5] kvm/x86: add kvm_arch_test_clear_young() To: Sean Christopherson Cc: Andrew Morton , Paolo Bonzini , Jonathan Corbet , Michael Larabel , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-mm@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 87A9540005 X-Rspamd-Server: rspam01 X-Stat-Signature: 18kc7f4scorirbyb8xpnfbk3ymi65ycm X-HE-Tag: 1677177310-184902 X-HE-Meta: U2FsdGVkX1+85ODc1hU/Qr3OJ7ShdSnYnepWRJP6NVmcCPxOippAJkE+eLPNcaOHRzX5RWBiHVKI+Hsg70UnEnxL2JBnWXpu1TtMUZP5/JARy3hj6p4waqhLSBOMqPsgquH6aYb0GfYHhJD0kXhNqMvHdje4T3ptBQlA0mAyW8ipESgXRTRRSICSIaMbRcRDBj8+pAOIzxGpfwKI5u9j4rQ7AGhbFkwnWH0OvlPsqAaolnkfw9xENXazCDy+dIAz8AbigInTrYW6i+NY+VoliQyF/2uxhmZbmRqIyusaB3XrVxCVkJmzE8g0kWrzu6ml+yBNyXX/pwpRAOChyA0SiSd0RYW1GUwiaKzEf5IhUU7LZHKrQIiFQGSkYSJASaPCdHTDxCNRk2AG51ijBaE1vFlRuX9weS6wEPWMbC0TQt9aBysZrmMIsr8+oO8AhW5jj0KcdRXdEc6pDWtrJ+eyfFoqBKNCJMRVQutJ0ZedMH4mgOXZTzRXULXNxH9DlXasWpNwIZpeDlVPFZ6ugvfwYF0qIAdELe8DnaGHcWugdimcXZHpYBImv//wCJzhmGUKu09dItQJO3zyoRaLcEfRTa1SXoEIBE9ANp6tlyZFlcNzTaEX3KF0anzfxFmZVlXrrqJcPSdKquEkuj7NlbKFHTf3A1gmw8+zKftvEWr3alaPP95fwpf8JKoHO38S69HAt3uVeOa/1j8BUht7S4FjPVLuNUC1xfboS04IqNyTJgNhFSdPkTHDCi4oeuSr7jSmO2u+aM6ChYsm3R8OMcsZczx1bfC7ySN5TZjHdE3vt77gxFWMlmdgDvRGitTfCnhnvzvysDvwUnYFnCwbXjYp+lby1WnZYEVx9eayHYc88ZpOgOsZtyllYfYZL+R1sjjnTyz3CFR/wM5asWhjTvZaF3PImpFCdxfmwWcu+VZVYkTB02pPu0IZuH3Hwf2frAShokyJ7a9PSKChzzwHvFL hT4Ic7vj hEjLwyE+OGWoFMw5ewKLZdzzgj3l3iChyfPe/a88xZ5Zj6BTWagNjYcGgrmp43qvMHpCxakYF8WzmexE8FI6E7p1YCY8BirJbmaV7NoMcyf3DDy9Dv1M5tzKpWgj8azCEenNBxsprmstMslTEv6wsdAIEaDWFQ/ICITF6Wf/VaWvchtDl4gd9O4mSF0O4nRLTUMYRRcjljbOUC3r65hBRMBwhyg+d/ZRr5sBknuspmyehlndsMyIn1ogojJJEHAZgjZAKj3K3TYW48ImXdQCVClfA6w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 23, 2023 at 11:24=E2=80=AFAM Sean Christopherson wrote: > > On Thu, Feb 23, 2023, Yu Zhao wrote: > > On Thu, Feb 23, 2023 at 10:09=E2=80=AFAM Sean Christopherson wrote: > > > > I'll take a look at that series. clear_bit() probably won't cause a= ny > > > > practical damage but is technically wrong because, for example, it = can > > > > end up clearing the A-bit in a non-leaf PMD. (cmpxchg will just fai= l > > > > in this case, obviously.) > > > > > > Eh, not really. By that argument, clearing an A-bit in a huge PTE is= also technically > > > wrong because the target gfn may or may not have been accessed. > > > > Sorry, I don't understand. You mean clear_bit() on a huge PTE is > > technically wrong? Yes, that's what I mean. (cmpxchg() on a huge PTE > > is not.) > > > > > The only way for > > > KVM to clear a A-bit in a non-leaf entry is if the entry _was_ a huge= PTE, but was > > > replaced between the "is leaf" and the clear_bit(). > > > > I think there is a misunderstanding here. Let me be more specific: > > 1. Clearing the A-bit in a non-leaf entry is technically wrong because > > that's not our intention. > > 2. When we try to clear_bit() on a leaf PMD, it can at the same time > > become a non-leaf PMD, which causes 1) above, and therefore is > > technically wrong. > > 3. I don't think 2) could do any real harm, so no practically no proble= m. > > 4. cmpxchg() can avoid 2). > > > > Does this make sense? > > I understand what you're saying, but clearing an A-bit on a non-leaf PMD = that > _just_ got converted from a leaf PMD is "wrong" if and only if the intent= ed > behavior is nonsensical. Sorry, let me rephrase: 1. Clearing the A-bit in a non-leaf entry is technically wrong because we didn't make sure there is the A-bit there -- the bit we are clearing can be something else. (Yes, we know it's not, but we didn't define this behavior, e.g., a macro to designate that bit for non-leaf entries. Also I didn't check the spec -- does EPT actually support the A-bit in non-leaf entries? My guess is that NPT does.)