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 X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29C41C41604 for ; Wed, 7 Oct 2020 17:30:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7BFD21707 for ; Wed, 7 Oct 2020 17:30:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Se9nw5Fg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728555AbgJGRaX (ORCPT ); Wed, 7 Oct 2020 13:30:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726511AbgJGRaX (ORCPT ); Wed, 7 Oct 2020 13:30:23 -0400 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC093C0613D2 for ; Wed, 7 Oct 2020 10:30:22 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id m17so3262238ioo.1 for ; Wed, 07 Oct 2020 10:30:22 -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=pQ3RmkMpjXxSLR81pkKdGt+TZH44v4hpamp0wM2Tbvs=; b=Se9nw5FgHFtKsm8GMYSImWv2wXIqCCOCv6pqlrWzBIvY0KyFKYLSgBJbdclE74rN0V L0OzzCyXjwmzqY5CvOwmW1s23GoVCPICapYUZFiSyQ3VzyBQJpfZ+6B7eKkncs8IsvXR slEUoHEbK3sqOXSRrw0ZRR2s39x9H1sNI4Ysl2tET0kOXOHkex1NPPywMNawv3w1f+sB c6lulPb33S1fRXiAC5OZMKjd4VOO5Q3jJ7RhTgSz7ELXfAEp8rJq7zc0JWvoRTDpcC0Q cTGuo3+wxAiYN9Cg6g/Jn6XY557RX4qkZ2GxwutbY+LCvSQ633tA4zpsHUJpBQTsLVbR lMZw== 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=pQ3RmkMpjXxSLR81pkKdGt+TZH44v4hpamp0wM2Tbvs=; b=gMFikUQnXQrdyR9do6Z0L0sifGCpUTK9ihRIdp5IiP2MfqRuDtPBzc6kgo5YxGfpHD nCmdSzcxD4Nwj9Z1zr0sOZ9ZDp6lOPt8G6pGcLMDWdqDX6HnAWUFhrA+/WiYr03t4zK7 MiCtbUu/NkKo0YwOAf9IGZMO+fou7JMgMkmXqTKNdPq1QcI+5S1FTsNxSvUMEx9jn8do x0c4SGx2666x3voYQfN6yDPm8uzJS/6wYyIFCe9ZyVoyiXSv1jc1WVB0E0a0HeCNEhcB 8eBMfyhlswT+i1aTbCd5vPajQpkpiTUzprZKKRqDZStP+mqRQ5rKM7aMTOBZT6/avZUR Iahw== X-Gm-Message-State: AOAM530fJdmNgu3dqIEynJQiqd8g2mO2P6g148vCI3B/veKcpOgYdhZo 3Lg6VnY6s97AJDOvZvh4HkebFnNVDXukDGadoTb6Tw== X-Google-Smtp-Source: ABdhPJytlhBgnWm3jW2tGSy64WkRj5mYfdnZRMLgkPXFNiRl5vrEqOTNvUu8Lz/HHEZVJWadIix3VN17uQKF1IQZXao= X-Received: by 2002:a6b:1646:: with SMTP id 67mr3090555iow.189.1602091821740; Wed, 07 Oct 2020 10:30:21 -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> <7636707a-b622-90a3-e641-18662938f6dd@redhat.com> In-Reply-To: <7636707a-b622-90a3-e641-18662938f6dd@redhat.com> From: Ben Gardon Date: Wed, 7 Oct 2020 10:30:10 -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 Wed, Oct 7, 2020 at 10:18 AM Paolo Bonzini wrote: > > On 07/10/20 18:53, Ben Gardon wrote: > >> 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. > > Well that's not easy if you have to think of which functions have to be > called. > > I'll take a closer look at the access tracking and dirty logging cases > to try and understand what those bugs can be. Apart from that I have my > suggested changes and I can probably finish testing them and send them > out tomorrow. Awesome, thank you. I'll look forward to seeing them. Will you be applying those changes to the tdp_mmu branch you created as well? > > Paolo > > > 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. >