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 71FDBC6FD19 for ; Mon, 13 Mar 2023 17:33:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230176AbjCMRc6 (ORCPT ); Mon, 13 Mar 2023 13:32:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229617AbjCMRcy (ORCPT ); Mon, 13 Mar 2023 13:32:54 -0400 Received: from out-11.mta1.migadu.com (out-11.mta1.migadu.com [95.215.58.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38C122CC66 for ; Mon, 13 Mar 2023 10:32:32 -0700 (PDT) Date: Mon, 13 Mar 2023 17:32:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1678728748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oSimWHYH2lVyX1VD90V/L4j8kwRRJGcNk5nCqgP2JAU=; b=PJWEINEgTzy0YHyxA+TAT/5Uf4XwnQ31PLXHuQjMDuRf52uTgSs7QXYtDY0Q3fnUWHUNEA VZmt2gRJbZxNQB0jx9pEuCeKv+LKcqFtjbIaLm/DZryoWMcWMhQw8ly7Ex+LLbxAoRPJGF YLAsnidmNXvS9vnD5iF/pMSLhPywr74= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: Bagas Sanjaya , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Sagi Shahar , Erdem Aktas , Peter Shier , Anish Ghulati , James Houghton , Anish Moorthy , Ben Gardon , David Matlack , Ricardo Koller , Axel Rasmussen , Aaron Lewis , Ashish Kalra , Babu Moger , Chao Gao , Chao Peng , Chenyi Qiang , David Woodhouse , Emanuele Giuseppe Esposito , Gavin Shan , Guang Zeng , Hou Wenlong , Jiaxi Chen , Jim Mattson , Jing Liu , Junaid Shahid , Kai Huang , Leonardo Bras , Like Xu , Li RongQing , "Maciej S . Szmigiero" , Maxim Levitsky , Michael Roth , Michal Luczaj , Mingwei Zhang , Nikunj A Dadhania , Paul Durrant , Peng Hao , Peter Gonda , Peter Xu , Robert Hoo , Suravee Suthikulpanit , Tom Lendacky , Vipin Sharma , Vitaly Kuznetsov , Wanpeng Li , Wei Wang , Xiaoyao Li , Yu Zhang , Zhenzhong Duan , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] Documentation/process: Add a maintainer handbook for KVM x86 Message-ID: References: <20230309010336.519123-1-seanjc@google.com> <20230309010336.519123-3-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 09, 2023 at 09:25:54AM -0800, Sean Christopherson wrote: > On Thu, Mar 09, 2023, Oliver Upton wrote: > > On Thu, Mar 09, 2023 at 09:37:45AM +0700, Bagas Sanjaya wrote: > > > On Wed, Mar 08, 2023 at 05:03:36PM -0800, Sean Christopherson wrote: > > > > +As a general guideline, use ``kvm-x86/next`` even if a patch/series touches > > > > +multiple architectures, i.e. isn't strictly scoped to x86. Using any of the > > > > +branches from the main KVM tree is usually a less good option as they likely > > > > +won't have many, if any, changes for the next release, i.e. using the main KVM > > > > +tree as a base is more likely to yield conflicts. And if there are non-trivial > > > > +conflicts with multiple architectures, coordination between maintainers will be > > > > +required no matter what base is used. Note, this is far from a hard rule, i.e. > > > > +use a different base for multi-arch series if that makes the most sense. > > > > I don't think this is the best way to coordinate with other architectures. > > Regardless of whether you intended this to be prescriptive, I'm worried most > > folks will follow along and just base patches on kvm-x86/next anyway. > > Probably, but for the target audience (KVM x86 contributors), that's likely the > least awful base 99% of the time. Sorry, I follow this reasoning at all. If folks are aiming to make a multi-arch contribution then the architecture they regularly contribute to has absolutely zero relevance on the series itself. > > It'd be easier to just have multi-arch series use a stable base (i.e. a > > release candidate) by default. That'd avoid the undesirable case where merging > > a shared branch brings with it some random point in another arch's /next > > history. > > You're conflating the base of the patch series with the branch it is applied to. We cannot pretend the two are in no way related. The dependencies of a series are not obvious when based on the /next branch of any one architecture. > I'm most definitely not proposing that multi-arch series from x86 contributors > always be routed through kvm-x86. It's ultimately the responsibility of the > maintainers, not the contributors, to avoid funky merges and histories. Right, but contributors looking to make changes across architectures share some of the burden of cross-arch coordination as well. Basing patches off of a random commit not in Linus' tree does not match at least the arm64 workflow. > If a > series warrants a dedicated topic branch, then we need to create said topic branch > off a stable, common base, irrespective of what the contributor based their patches > on. The lowest friction way to coordinate such things is to start off with a common base and go from there. If there is a compelling argument for doing things differently in the context of one series then let's talk about it on the list. > If a series from an x86 contributor applies cleanly on kvm-x86/next but not on > -rc2 (or whatever), then the reverse would also likely be true (if the contributor > used -rc2 as the base). This can be addressed in a merge resolution, thereby offloading the responsibility to the maintainer. > In other words, for series with non-trivial modifications > to other architectures and/or common KVM code, IMO the base used for the _initial_ > posting doesn't matter all that much for us maintainers since such series will > likely require additional attention no matter what base is used. In all likelihood, sure the series will be respun. But, you're offloading the responsibility to ask for a sane base on other arch maintainers which I'm not cool with. > On the flip side, the vast majority of "multi-arch" series in KVM tend to be focused > on a single architecture, with only incidental contact to other architectures and/or > common KVM code. Those types of series will likely be routed through their "target" > arch tree, and so for x86, using kvm-x86/next as the base is preferrable. With long term aspirations to share more code between architectures (e.g. common MMU) I believe we'll see more changes that have meaningful interaction with all architecutures. > My goal with suggesting/prescribing kvm-x86/next to contributors is to make the > easy things easy. On my end, that means having _predictable_ submissions and > minimizing the number of avoidable conflicts. For contributors, that means having > a very simple rule/guideline. "Use kvm-x86/next unless you know better" satisfies > all those conditions. I believe "Use a release candidate unless you know better" for multi-arch changes is just as simple. Better yet, it clues in contributors as to how changes are coordinated across architectures and might help them know better next time around. > > If a different approach makes sense for a particular series then we can > > discuss it on the list and arrive at something agreeable for all parties > > involved. > > > > > That means patches that primarily kvm ARM changes should be based on > > > kvm-x86/next, right? > > > > No, don't do that. > > + > > This doc is specifically for KVM x86. You've also made some suggestions about cross-arch development that do not fit the development model of other architectures. I have no desire to nitpick about the x86 process but want the multiarch language to actually set folks up for success working outside of the KVM/x86 tree. -- Thanks, Oliver