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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DBE6C6FD1D for ; Mon, 20 Mar 2023 18:49:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229671AbjCTSt2 (ORCPT ); Mon, 20 Mar 2023 14:49:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230361AbjCTSs4 (ORCPT ); Mon, 20 Mar 2023 14:48:56 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A7543B228 for ; Mon, 20 Mar 2023 11:41:52 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id o10-20020a17090ac08a00b0023f3196fa6fso4633984pjs.2 for ; Mon, 20 Mar 2023 11:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679337690; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=AGeXag6D9kuvOFx10JcqNN4G7nzKqx8n4sK14frGlkY=; b=U9P4ktn0YkzcsNkjKO3O3Ey5KGceaGAI7p8ldXV5RZsiQx9D4pGgPcVlI5C5vcEaYi 7ZFwggQRCDcnL66/e8kG6/yQPeRqQkJ7tSSaWU6/M4thn/MQl3cr4eFvjv3DTepgVjmP AfGzt3REUcyAZDjcMXz71BUJb0TOBK3sMUTx/VlSYrmtGgsDuO3EggSfIlYDOHw6+pBF BQNiej9HV/+MHQez+BeYly6UZuuNT4NgTYuIvFarBCrpOezD+q6wLcky0yinYb0u9QyT cr6jS7cjEoGgb1PSgJv0kqBU/GkCjFDI0qZz8inr6QOpPMZJnojb6MGHtuSCWIDBXJZK M9vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679337690; h=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=AGeXag6D9kuvOFx10JcqNN4G7nzKqx8n4sK14frGlkY=; b=AuLyqK7ULoocbUliGU7xzB3CsMCTeMBjRgbZs7I0OUWl2SGpdlH3ToWL7lm+bJZtpI a0hnQELiZzoO/UPFfyLWUNaPADmc+ScgvWlsV360Qdvu90/vsZc/QixOZC1NDu+czN33 DO5nzow+8T4FU4kAvtvfUQUqOxvVN7qtcMtSwKeTsLgj9BJIncIVZFmf4D8x4TZge3Nr mSXgenia2+FQAPFKFkfb6ljRYTbOxsvYvz/VTtKHjhht3HisT0HTtvJPyAc/EfAbHhUz nIkN8ghnPzr+TK0BXt23I1ljeeIMFwHYy5sbwSZ1TcEZKSV/VTUAnlYzi5/2IlABSunr +r/Q== X-Gm-Message-State: AO0yUKWqAinldQjyLbdWvZHzMH53MDNdrhTgAuhBg6g2F3ZNWjT5GOyK 2bQ2x5mce5oOIfQKvZzLPD6dhDsDh2k= X-Google-Smtp-Source: AK7set/pLysGBEI7iu4qioNRYT41BiTPna9N6cshhvM7P4GCwyT22Eawv1P1/8/vvJ5fs130lwI3yr6ZPlY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:db09:b0:1a0:4be5:ccea with SMTP id m9-20020a170902db0900b001a04be5cceamr6937261plx.9.1679337690302; Mon, 20 Mar 2023 11:41:30 -0700 (PDT) Date: Mon, 20 Mar 2023 11:41:28 -0700 In-Reply-To: <20230202182809.1929122-10-bgardon@google.com> Mime-Version: 1.0 References: <20230202182809.1929122-1-bgardon@google.com> <20230202182809.1929122-10-bgardon@google.com> Message-ID: Subject: Re: [PATCH 09/21] KVM: x86/MMU: Move paging_tmpl.h includes to shadow_mmu.c From: Sean Christopherson To: Ben Gardon Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Peter Xu , David Matlack , Vipin Sharma , Ricardo Koller Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org First off, I apologize for not giving this feedback in the RFC. I didn't think too hard about the impliciations of moving paging_tmpl.h until I actually looked at the code. On Thu, Feb 02, 2023, Ben Gardon wrote: > Move the integration point for paging_tmpl.h to shadow_mmu.c since > paging_tmpl.h is ostensibly part of the Shadow MMU. Ostensibly indeed. While a simple majority of paging_tmpl.h is indeed unique to the shadow MMU, all of the guest walker code needs to exist independent of the shadow MMU. And that code is signficant both in terms of lines of code, and more importantly in terms of understanding its role in KVM at large. This is essentially the same mess that eventually led the cpu_role vs. root_role cleanup, and I think we should figure out a way to give paging_tmpl.h similar treatment. E.g. split paging_tmpl.h itself in some way. Unfortunately, this is a sticking point for me. If the code movement were minor and/or cleaner in nature (definitely not your fault, simply the reality of the code base), I might feel differently. But as it stands, there is a lot of churn to get to an endpoint that has significant flaws. So while I love the idea of separating the MMU implementations from the common MMU logic, because the guest walker stuff is a lynchpin of sorts, e.g. splitting out the guest walker logic could go hand-in-hand with reworking guest_mmu, I don't want to take this series as is. Sadly, as much as I'm itching to dive in and do a bit of exploration, I am woefully short on bandwidth right now, so all I can do is say no. Sorry :-(