Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp563056pxu; Wed, 7 Oct 2020 09:57:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNjS3JSws1z2d5v4uRJIL3i5OHj6QVgZ2VPlfhCWVaWdRw6FzA53NenpT+Kk1F6qc560Uq X-Received: by 2002:a17:906:a947:: with SMTP id hh7mr4162989ejb.126.1602089843921; Wed, 07 Oct 2020 09:57:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602089843; cv=none; d=google.com; s=arc-20160816; b=WxmNRwNcm4JFf0l2xVyv3mbBbmzt6mYk0hxqwaVdNvSBUiCBn/qjZfiqT+1qejew/w 1g9khhhInnc7cxEt9rwJqgemonfJ2oaF+vKSjicXOMfkA8o78ba0/qRtbTw0H///NEK4 RXyZCB2N3HTEUFalhLNdYHP2/WeCDET/8OGyxm7A6MhqmwPoRjocV3ZUlfhvupizHqV3 34LqCwK3cig46fQJE657Ip9AfEWFYch3qTFL/uhCJjLlIxlzQN7+PoElLG6YN+PrE6co MoZj+jJt9KENwl+F5iWiT5z7nBgm4dJUtiB6V91D8qVdB4wptetQz1CSi1VLMZCOKaFv nOLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=nDdFpy68M4qcIzjp5XTKty3VRwf5DXuMbkrk++kW+nE=; b=wvPY0WrJIUlHqa2YVw9ryYsnIB9MzQBzmyPXbMysBJ6I73v6rvOduySnYNs0WBgCO/ Cv10tfeY4V02h8TjQUG4iFulza+n42L18cDgrMFqjtsU34HdT6RH6rDjTWWZFx4JlLvS GZWHswjZyp4O8j6DuC8d+5IhW9KYZSV4wTOHSnG8T5Ph3iqDYB4ayTiRsnfq9QBTUFqF IsHgTAR0RofSwT4qWZ7p45IAsTWZfxokaEEOvNIRMEdc/t1qS1TmByQwlfZ/OrvpO+xe 5+O5XrCycr5us4lRj7YDtxPlvIr3Rq+ciHZjWCan20nXyR29anHHKo7UmuXZ97BqEHe2 rxAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NJ+883kU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qo18si1838095ejb.161.2020.10.07.09.56.59; Wed, 07 Oct 2020 09:57:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NJ+883kU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728195AbgJGQxd (ORCPT + 99 others); Wed, 7 Oct 2020 12:53:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728051AbgJGQxb (ORCPT ); Wed, 7 Oct 2020 12:53:31 -0400 Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF4B7C0613D3 for ; Wed, 7 Oct 2020 09:53:30 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id n6so3044101ioc.12 for ; Wed, 07 Oct 2020 09:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nDdFpy68M4qcIzjp5XTKty3VRwf5DXuMbkrk++kW+nE=; b=NJ+883kU7p70HCRlrjwPHALnKwuBGBHt5ndHWo0n/reWd61Gz99+NtoeWL1TUkeMzg lhuT7M+Z13S6MZjZD0m9uVCbRSWrts7qvF32MDIGkygCzj8/vkosUGfrOCsbZMQnb/eP z8AKbViiBxfxSd1TSGjNym04Z/Ma654XyzTLahNgEUwQFoS0hEEbBXFGjvROrFSZJDMP InC71Do8rR55zxc83vTXNtr8MFiqCSSu2o7EzRTWYcrOwBfZ9J3kzWC20uHjYEA26/Dj oyZSkNxE3W64MAm/+ZQ0ErgTRbTUBsTvbVgYvARD/mei0aehqIsUsjoCt+HnfHrs4LQc HcFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nDdFpy68M4qcIzjp5XTKty3VRwf5DXuMbkrk++kW+nE=; b=KfAa3MrNrg5xc+9ycDkKunn7461HwSINWaRss73m4M9s3ocohesFm7VGOgP7fV0WUj N0+9KpjG5y+SzC4nJHzDj1fbEHjoiSgzoGCG+Jachydd+J0cvf9rL72GfPLiie/BONUq Mtgloa/kcBE9SxzowBTF6jRRjPn6DtUFWS2F1O9vJf6AKNQFW4ZhdJ1kkaXwspUdjiF2 zit1BhRDCGmZpJ4MzMvjumK9MiImD7I+S3kkHAxqc1VOIaMJGZ8scMBbCtCHFSNzMJGh oC4b5ray/P1uA/Laj8mozos0uodm5wajuyW2aKl6ydES+Pkpl7Vqw70yEuSX8lg/xsyW /d+w== X-Gm-Message-State: AOAM533eTcGhLL6L7op1yDzK1zTxHO1AtnMCbJAbn5XfXE7Tcw1yinhw 1mw04lRCMiNZe20SfdpVYzWxtxFpg3I/tvFTjF82wTtMOnb8GP4t X-Received: by 2002:a05:6638:1508:: with SMTP id b8mr3620771jat.25.1602089609707; Wed, 07 Oct 2020 09:53:29 -0700 (PDT) MIME-Version: 1.0 References: <20200925212302.3979661-1-bgardon@google.com> <20200925212302.3979661-16-bgardon@google.com> <622ffc59-d914-c718-3f2f-952f714ac63c@redhat.com> In-Reply-To: <622ffc59-d914-c718-3f2f-952f714ac63c@redhat.com> From: Ben Gardon Date: Wed, 7 Oct 2020 09:53:18 -0700 Message-ID: Subject: Re: [PATCH 15/22] kvm: mmu: Support changed pte notifier in tdp MMU To: Paolo Bonzini Cc: LKML , kvm , Cannon Matthews , Peter Xu , Sean Christopherson , Peter Shier , Peter Feiner , Junaid Shahid , Jim Mattson , Yulei Zhang , Wanpeng Li , Vitaly Kuznetsov , Xiao Guangrong Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 28, 2020 at 8:11 AM Paolo Bonzini wrote: > > On 25/09/20 23:22, Ben Gardon wrote: > > + *iter.sptep = 0; > > + handle_changed_spte(kvm, as_id, iter.gfn, iter.old_spte, > > + new_spte, iter.level); > > + > > Can you explain why new_spte is passed here instead of 0? That's just a bug. Thank you for catching it. > > All calls to handle_changed_spte are preceded by "*something = > new_spte" except this one, so I'm thinking of having a change_spte > function like > > static void change_spte(struct kvm *kvm, int as_id, gfn_t gfn, > u64 *sptep, u64 new_spte, int level) > { > u64 old_spte = *sptep; > *sptep = new_spte; > > __handle_changed_spte(kvm, as_id, gfn, old_spte, new_spte, level); > handle_changed_spte_acc_track(old_spte, new_spte, level); > handle_changed_spte_dirty_log(kvm, as_id, gfn, old_spte, new_spte, level); > } > > in addition to the previously-mentioned cleanup of always calling > handle_changed_spte instead of special-casing calls to two of the > three functions. It would be a nice place to add the > trace_kvm_mmu_set_spte tracepoint, too. I'm not sure we can avoid special casing calls to the access tracking and dirty logging handler functions. At least in the past that's created bugs with things being marked dirty or accessed when they shouldn't be. I'll revisit those assumptions. It would certainly be nice to get rid of that complexity. I agree that putting the SPTE assignment and handler functions in a helper function would clean up the code. I'll do that. I got some feedback on the RFC I sent last year which led me to open-code a lot more, but I think this is still a good cleanup. Re tracepoints, I was planning to just insert them all once this code is stabilized, if that's alright. > > Paolo >