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 BD32FC636D6 for ; Thu, 23 Feb 2023 19:02:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43EFD6B0072; Thu, 23 Feb 2023 14:02:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EF016B0073; Thu, 23 Feb 2023 14:02:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B6E86B0074; Thu, 23 Feb 2023 14:02:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1BFBD6B0072 for ; Thu, 23 Feb 2023 14:02:44 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B8E4F120577 for ; Thu, 23 Feb 2023 19:02:43 +0000 (UTC) X-FDA: 80499478206.13.2EA71AB Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf09.hostedemail.com (Postfix) with ESMTP id DF38414001F for ; Thu, 23 Feb 2023 19:02:41 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qBTuRujl; spf=pass (imf09.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.48 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=1677178961; a=rsa-sha256; cv=none; b=wVX22xcZ4OFAb/66jGyi5/HbcnLxMX2/G9h28Ax4w7ydLIQkVcfTAHZiAWDSUS+z8h8ztD 7LuXuqSAj2hzMQDuC3YJLFW/VDEP42uggV8Q0fSWqgqrt0uxH8SfzZKoVkjYTcc3QmQNMJ 8xvSPIgZsjgTX7lUBAho9VJCWwnj384= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qBTuRujl; spf=pass (imf09.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.48 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=1677178961; 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=BehNjNr/+dUxmpuFq2DtkAvQP7yK7v98nPDghIFQheY=; b=O3Pz3UL2mXo+pGgSh2xfGtBRwmf5WKDqrAZZcxkK+uS3ayRLKSEQCz6rIZjCSQ1qSUR7op LgqPVLGn1amtug9tUyPBtQ2MsFHMq4Ld3wS/DVmmIfxjUgqlZ0HWytBgk9P14uuK/Gtg+A BGolRwBffdBHYo8RCTAlJHwcN+PPzkQ= Received: by mail-vs1-f48.google.com with SMTP id d20so9633265vsf.11 for ; Thu, 23 Feb 2023 11:02:41 -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=BehNjNr/+dUxmpuFq2DtkAvQP7yK7v98nPDghIFQheY=; b=qBTuRujlvCa1VgF13+Ud5voDEv0Q9s+atY0zVj2JYk9FiZWoLxhWXRpAJXyIzrim5w f+xS7avGfjvvGDxpRiJfIop5uZFSmQbUhiuEHUwLF8lmT75u4h6jwYfZYix0l5oKm0n8 01JZrrnbVqjuYQeeGAqe+qGSzs3xRAnVpo0FM0OQEyk76yvi0N68VRkv3yDf6aS8eKYM Yz5hQW8ZjbU4RJ+5Rgvt8ZQpO6vql2HM/mJBiV/J+VEhgrmp/S+g+H88b6V/rs8lo71z djQQH1BHv98oah+DOIANnbXcpil5WQ0qSt5u+yI6+vaPMHi3OyELJdFhefr6sUFfgv9d FCCA== 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=BehNjNr/+dUxmpuFq2DtkAvQP7yK7v98nPDghIFQheY=; b=j9fnurAbRozEQn6D9MoWaMoDtyFxpOCoc8iTBzyvIUyLy++P6OqTC5HRUk7+/EmdJI 2AwiyJoZJhU8cERPEbA6Chhoh8HCW6Bs43DtRQkZkcUHorjjpF9SY4Mi2pWAxB3oE1Be bCNZcmyf4Hp71fj+W/JbkxU4foy9Ma7oq83P9Z0kQW+fegCKbdrtJ40SQlEE/NQB+u4G C9LByhDVkO9k6rLPbiyW+WhZBigk7gHmt5h5LBzsHNwCONux8cS3LSZ8z59zwzn7nyx1 H1H/d//+/KIZKF/NaIJS0BG8Wy4HN3ZzUTP8tZRzVmJHHLVK2dY1vSqoQXEIuHoD/Fgc n12Q== X-Gm-Message-State: AO0yUKUmnUaCaqZWCGTjGN/RqvV0tjm7YWg7BMe1Qg7/WSJQPLFCwsJj lYr3rK0cjqaaFu749H03S8fS3LfWH0FeX0gMj7U+KA== X-Google-Smtp-Source: AK7set/Hhw/cCSkdxYcIh8mHlA+djGYcnBHqhr6GbdkbHFHfRZfMKdXhnPCa3oQXStWL9Hm3w7gevCyr1XzyoL4fUiY= X-Received: by 2002:a67:c597:0:b0:402:9b84:1be4 with SMTP id h23-20020a67c597000000b004029b841be4mr587075vsk.6.1677178960791; Thu, 23 Feb 2023 11:02:40 -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 12:02:02 -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: DF38414001F X-Rspamd-Server: rspam01 X-Stat-Signature: phcxpn1erns4un7dugg5ij5nznyuspud X-HE-Tag: 1677178961-88573 X-HE-Meta: U2FsdGVkX19VIv8JLrwkGR1FO9UX7rBgVMd96R9neTaNiZMB90k/OHbd+0cWgzTvscthVznUYW+TT6OqiEWu4pvNnKxvu5nq5Cvtzo+G9BK+ru8PHwUih/1ldxMI0dYB5xuf+KCEdM/DAm6/u66sxzWN3bSj/lJ6ZtoRBPpl7R2nWzMHRiBQXcTNfRyXENGo8S5QQHMXsgQe0tmH9ikS5JBE968OwUXK+K5GA+CtpnoynDFr4686ZG8DJzYiZUgtKPkZ/ujIY2DsPqHLvIT27LSTUfFCIUvqOHOxEDDC1uLkMB1GWoNDmHhrm8TmBmryhXd8xCHyOvOhLhO1YIjV8wq0Y/57w/p6NXcAfXdFUWnKmIJY2Bmfyez1xtuMiPqvz1uLn8lbKqQe7Trsv0MFOAX3YILuryKZeBDw8vC/DfH0ejkXV1O9Hz3CgNIRJ+6poKHlJmtAzISWz5uOVwGH28ai4Gp4narr+xTsur/Syjfbc9DpXBWEHxcUVNSs7bDX+u8IS2wI129TIc44XuAOHlWyALGiGAz+avIa5b+W+HlPxzBjGQa4/vZkPMPSeRLTSsl3Nbl4ZT3e2S+YRn39zMIUSUPmR0ntWpmv4QAwMsxEJFT/bCXhQbeUrwcKphzeYVlDJMluKjb7yReaw5x9iXCNPR8EMcrMaDl+w9WcC9UyHRCOkABfW+n10S0Zf8jNmRrJU5eF7zgLCog2u/MI7WqR9W6D2spMW7d2aQcREQSZkwZinDwJ57gHy32InyXpESFJvHhlJorchWmhrTXPzYbwFVkNrok4UrwFAQqi+npYHnUIMlfIRfJBcnfC/csMHAxysv1SF5ofD0vvTrfjOmbCpQdto61aSBMGimR1bSC6mrqsLl5/6yQCoGT/CvUSMRtKv2LWXl+NdLPk9T4+ku9OG2qNhRAoYsKKi7X0ER/fcnzQIrOP434rKZDN3fB1FdbM40qB0m9lcPF+GFO cV5itq3K wbWc0c8f2hZX8CIhtV2sv73LkTE95kIO5nG2T9zMyozNv/JBJh1eoB0I2shzCL0td+yKLnrEk9WEjn6PPakKwvf0O8IuQdCMjb9b57/3xBzWtQ4ng69v9mD19iDSvSTYOawcgA6drkTACTjnzc7Zgeftt6GknLbv9lpOJ3uSfvvG4mNmMx8HraDzGqgwIAzZj0/ehHeBDuBsMWNT/RtsMWon6BJL858GQVZqB8mcSBB2oXzPOrcePTuIcNI26xAz5fAI8WlnuZ+C6MfPsFHMc6ukkWzm1r50q6KNlOO1Ww+8rS+LcMRqenoaWWem3f3ETg33xs2jopAQ0nZUEMf+siSz1bvsDiEU15ObqJYxUxXgSRVw147iduWQtVd2teaXdvnHPRkNVqG0E4fVYTTo/c36Hcigj4I7w4BYgWvYNjxdyGlbxbN8pz/ZF8g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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:47=E2=80=AFAM Sean Christopherson wrote: > > On Thu, Feb 23, 2023, Yu Zhao wrote: > > 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 cau= se any > > > > > > 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= fail > > > > > > in this case, obviously.) > > > > > > > > > > Eh, not really. By that argument, clearing an A-bit in a huge PT= E 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 PT= E > > > > 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 beca= use > > > > that's not our intention. > > > > 2. When we try to clear_bit() on a leaf PMD, it can at the same tim= e > > > > 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 pr= oblem. > > > > 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 in= tented > > > 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. > > Heh, by that definition, anything and everything is "technically wrong". I really don't see how what I said, in our context, "Clearing the A-bit in a non-leaf entry is technically wrong because we didn't make sure there is the A-bit there" can infer "anything and everything is "technically wrong"." And how what I said can be an analogy to "An Intel CPU might support SVM, even though we know no such CPUs exist, so requiring AMD or Hygon to enable SVM is technically wrong." BTW, here is a bug caused by clearing the A-bit in non-leaf entries in a different scenario: https://lore.kernel.org/linux-mm/20221123064510.16225-1-jgross@suse.com/ Let's just agree to disagree.