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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B44BCC433E5 for ; Wed, 26 Aug 2020 07:15:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 97CD52071E for ; Wed, 26 Aug 2020 07:15:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726798AbgHZHPA (ORCPT ); Wed, 26 Aug 2020 03:15:00 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:37389 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726698AbgHZHO7 (ORCPT ); Wed, 26 Aug 2020 03:14:59 -0400 Received: from mail-qt1-f179.google.com ([209.85.160.179]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mk0a0-1kvBwf1TTs-00kRea; Wed, 26 Aug 2020 09:14:57 +0200 Received: by mail-qt1-f179.google.com with SMTP id 92so718948qtb.6; Wed, 26 Aug 2020 00:14:56 -0700 (PDT) X-Gm-Message-State: AOAM532NZ91CydDDFgF41edtRYot+cE0wnTAgd3Y3/XaQn75w/CnIHtT twhhN+OsckwUc6veJjV+2eqjMFd0Yt9uKLRZqQ8= X-Google-Smtp-Source: ABdhPJwLuGjkmlnft754xbUklzGWtHhgTglHwx7onxQfpdw4FEOyMnyaABTTrq89Agj1YnTZDmfbHPSjkpJNT1I0q7s= X-Received: by 2002:ac8:688e:: with SMTP id m14mr12988809qtq.7.1598426095918; Wed, 26 Aug 2020 00:14:55 -0700 (PDT) MIME-Version: 1.0 References: <1598287583-71762-1-git-send-email-mikelley@microsoft.com> <1598287583-71762-6-git-send-email-mikelley@microsoft.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 26 Aug 2020 09:14:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer To: Michael Kelley Cc: Will Deacon , Ard Biesheuvel , Catalin Marinas , "Mark.Rutland@arm.com" , Marc Zyngier , Linux ARM , gregkh , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , linux-efi , linux-arch , "wei.liu@kernel.org" , vkuznets , KY Srinivasan , Sunil Muthuswamy , Boqun Feng Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:CfQNSp9K2Sdd2RppPCh70mApHLnySRUQtQTPs+NNnr5FwrxVCng AGs3F+IWIItB3FT7rCqPXYb5XyGGoFDhSK+bnnEr60dbVKDCRHARjKlBpi9MGbX9vXdpJbU azeTOu7yxAaAs+27q0YE9uN75kTAtAWNeCuEW0hI9gtCn99zyIo1UbdlbrW44jnbuGDBVXK MznMJZzDDYN2Qs5DfuJng== X-UI-Out-Filterresults: notjunk:1;V03:K0:xO0XMxW3dlA=:vjc8OvsMhX2drfQa3Dri8w oq47fIAjowurvD4ZZkt++2rnBezU79/Rzrl2CPXjVZ3RvhKchD4luPVKF0RsuCsaVJ6LQva0q FMy/z3NyQyst0i9tHN/MfHjMpU9mf1VBQTa7RmkhfUXTQpMuo1uP7j7itn3rCJE7ixmqjoSBy SNAGr8zxtJBQoorgvrwsjYaX0FVytV6ZQBlETXDbi3+qvQKDg+gYXlulRd9niBZ+pn5rlRgG0 wLjz8LpwEjE1UqKkJX8X9sVaHsSURyNOe78N+KO7fwZjTY/o9UJSzHMZlYovb/eNEBE5LveLp +/n+C8IrI4FUR9Da86VkJSRKqTXynBnI1Rd6nLJ6Y6iJjbSFL3FssDtesh8y3osxThKWsiESz O5NpdHIhQx8YrMovHWylmbB/Iizpaj51h+RTcmYFNFcO4dwZ97+oRTTAKx80+kTPqMtueaqqa a4joAYmuzbQ9/0ZTfbEHecvdeXYS0Qs7k/ejk9em39qknATRFaEK4wfFvRoHUYVEpHby/p/Eq zNnYZ7z1KGc2Ti9bJCG6UFLhwQa0VvtYi4A/1qkwDECB3MjvpGKjmSwSbHztJVYnIk9sNQxXm Kzw5m5i40W0U8wwsHJUm3a1Q20GNdof1knYfMX77zXRJ4GMtaC2dUSnhaEFej7+YLdOrsEDK0 +AbCRXHPoN/phSj6191B5V+/jUIxsXPmeD5SyMl4/l17XfjJYWw9KGZglpFmqTdf6JsDD4v1x YF9JL2OX7YX0nrJCDXmpF7mJVdihvVHe6fVmAFhTAJCbAO/ew/KCOtQ8Rh1vF5vmTzrxNfOyR 5OIftf6uZV5xVzlzAgOG5KJ5w8zn9McySso6Gi1tWQSTXJyaykpM+Gie0fGL2fKLPQ1HlJC Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 26, 2020 at 12:04 AM Michael Kelley wrote: > From: Arnd Bergmann Sent: Monday, August 24, 2020 11:54 AM > > > > I'm not sure what the correct solution should be, but what I'd try to > > do here is to move every function that just considers the platform > > rather than the architecture somewhere into drivers/hv where it > > can be linked into the same modules as the existing files when > > building for arm64, while trying to keep architecture specific code > > in the header file where it can be included from those modules. > > OK. The concept of separating platform from architecture makes > sense to me. The original separation of the Hyper-V code into > architecture independent portions and x86-specific portions could > use some tweaking now that we're dealing with n=2 architectures. With > that tweaking, I can reduce the amount of Hyper-V code under arch/x86 > and under arch/arm64. > > On the flip side, the Hyper-V implementation on x86 and ARM64 has > differences that are semi-related to the architecture. For example, on > x86 Hyper-V uses synthetic MSRs for a lot of guest-hypervisor setup, while > hypercalls are required on ARM64. So I'm assuming those differences > will end up in code under arch/x86 and arch/arm64. Yes, that absolutely makes sense. > Arguably, I could introduce a level of indirection (such as > CONFIG_HYPERV_USE_MSRS vs. > CONFIG_HYPERV_USE_HYPERCALLS) to distinguish the two behaviors. > The selection would be tied to the architecture, and then code in > drivers/hv can #ifdef the two cases. But I wonder if getting code out of > arch/x86 and arch/arm64 is worth that additional messiness. No, I think that would take it a little too far, and conflicts with the generic rule that code under drivers/* should be written to be portable even if can only run on a particular target platform. > Looking at the Xen code in drivers/xen, it looks like a lot of the Xen functionality > is implemented in hypercalls that can be consistent across architectures, > though I was a bit surprised to see a dozen or so instances of #ifdef CONFIG_X86. > Xen also #ifdefs on PV vs. PVHVM, which may handle some architecture > differences implicitly. But I'm assuming that doing #ifdef > in the Hyper-V code in order to reduce code under arch/x86 or arch/arm64 > is not the right way to go. In general that is true, adding a lot of #ifdefs makes code less readable and harder to test. OTOH there are cases where a single #ifdef can be useful when it avoids adding a larger amount of complexity elsewhere. Many subsystems try to restrict the #ifdef checks to header files while keeping the drivers/* code free of them. Arnd 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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 6C867C433E4 for ; Wed, 26 Aug 2020 07:16:30 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3DA1820767 for ; Wed, 26 Aug 2020 07:16:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iPmCgHcr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3DA1820767 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=T0iVMHRVvcA92XAsliWu2s9sIMVvwf3TFn+FtUFsX6I=; b=iPmCgHcr8DS24DiYoEdbYWhQ9 9T681XaDfI+LlB46b4WWmQQBXGNC9FBvR0PQMDBi2lwWtiy2d+/tBBb501m0z7hqlQpSCkv5jnM/n nSH+fMIlvMD9SBrgOw2+QYI7b6Yk4kHKnTugGlB9NDEdy9xLMbWSs20TDtz08XCp1D9siyncRP5mj C5yh+4cYR3sCDDrGIXhCGSXVU10vNgn6KFVSEF+ZHVyJHpzBZZCW2MBO1Q0sDL4wm8J0dqbZxQOD1 O6kx/mjuv4Kig2zgG+TkpqYefhe9RW3WAyXvu4+EbvNo2ytthbvJpzPHb8bfHE3BhB+5C1p37BL1+ nY8a2Cpfw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kApeE-0007GB-5e; Wed, 26 Aug 2020 07:15:06 +0000 Received: from mout.kundenserver.de ([212.227.126.135]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kApeB-0007Er-Q7 for linux-arm-kernel@lists.infradead.org; Wed, 26 Aug 2020 07:15:04 +0000 Received: from mail-qt1-f169.google.com ([209.85.160.169]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mo7Bb-1kzKXa0YTj-00pfhd for ; Wed, 26 Aug 2020 09:14:57 +0200 Received: by mail-qt1-f169.google.com with SMTP id n18so740837qtw.0 for ; Wed, 26 Aug 2020 00:14:56 -0700 (PDT) X-Gm-Message-State: AOAM533bsVLaV5EKYQZeLzXW3msiv58iAwmAn/Of/O2fafWpwMAuriAY w4IVEr2MBvHRSKDe/d7BxSSsBvWXFtg7YKzpZ9I= X-Google-Smtp-Source: ABdhPJwLuGjkmlnft754xbUklzGWtHhgTglHwx7onxQfpdw4FEOyMnyaABTTrq89Agj1YnTZDmfbHPSjkpJNT1I0q7s= X-Received: by 2002:ac8:688e:: with SMTP id m14mr12988809qtq.7.1598426095918; Wed, 26 Aug 2020 00:14:55 -0700 (PDT) MIME-Version: 1.0 References: <1598287583-71762-1-git-send-email-mikelley@microsoft.com> <1598287583-71762-6-git-send-email-mikelley@microsoft.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 26 Aug 2020 09:14:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer To: Michael Kelley X-Provags-ID: V03:K1:MeFh7NIrPXpBOq/n1JcgKv03a5/eyNqB7rPpEZ6Kiz+I5cUGGWz bhKERPNl5LTjra2Ojv/7ZEGutzrJMqUhX5qtTVJuORM8TYRnvrOzzS8OfHlA89eqLrl0mS+ 54mOezgICTzlQuunl9BHd3mUVvq1TJkxM1P0UuCLEoC1+ueT9OPjSWKSZ6PoYWjhPI1LEEr hhLvLlMwg2ubArMfDFx4A== X-UI-Out-Filterresults: notjunk:1;V03:K0:NccTGmwR+os=:eAynAT3JLKbR12hOZQ322i TPlG3TePp7wlpXHpaJdvjoFeGtrCMSb96/JmldZdOe67M5Sq9z0s7kzezRxERj0qS/RzQqy5K CRGquhWo/mrIZS/QwW3JAY88A0+xe/smv3HmzvhZyNVpUUQhTduBP+wTxnX5H0DohcZXCOF2/ oucY7LWMQ9LIehUKbISYLJEPm280iahhwmKdQ2oYh8JHvhquuKoO+P62OLoyF6XZSTqYroQo1 U2Cj6IXoTNzS38/D5dbqNP3w6l2tm7xr48u2y4nQ9CgnlV7uZA9ERfnNamXJ/o/dkXXzBnbt3 4mFFHXZvSSN60plhv7GKKWiLSRP9YLG+k9xgnFoiXQIYKzzWmhq/UMAnHFonDXrydIER2aHC4 6DzjJp8+TQuzbgIwngalIsswa370B5/ErgkWrT6kMy/iIdAohJJMP3B09f4QGRXYuZvzJlpXp RQMlLuECahcnFutnN1X9lnubzM4+QjIAky+VKrwX5oTXrCicdkc+5/02zPK8qIJLVtD4EiQ4g z0NrYpUoaEhNbrmIpzoOsMxv+TCl9HpuqdNhYAisOOk6NS/XRKc2KXnh0JqTQL5mv66TEYVMf TscSkc7b0fyPxKNHPJO7YC+6E7h5Lcw16qnKKCaL7iKrVhyLmpCrGioD2Bw848OGu0cRXtC5g 2wFnWXAGD7IOSwH3voN5fUYhrDy/0xwws0jfV0Qg4YiS71E22EOnTx6TouaoCOzE/3QHtTE/f gw0SHhaLL+E4JKYYRKA4DglUkmy6QyeqmtBXvtNUOYDYBXAE49h1ZRthu1TDl8Qb31MvCmV5R z6bLeKD5BWiCqpUcC2lmgl+/e6amhn7h84fxcB/JmaRq7migCIUJq/6xm3thIThJKTWYqoF X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200826_031504_087415_88595236 X-CRM114-Status: GOOD ( 30.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Mark.Rutland@arm.com" , linux-arch , "linux-hyperv@vger.kernel.org" , linux-efi , gregkh , Catalin Marinas , Boqun Feng , Sunil Muthuswamy , "linux-kernel@vger.kernel.org" , "wei.liu@kernel.org" , Marc Zyngier , vkuznets , KY Srinivasan , Will Deacon , Ard Biesheuvel , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 26, 2020 at 12:04 AM Michael Kelley wrote: > From: Arnd Bergmann Sent: Monday, August 24, 2020 11:54 AM > > > > I'm not sure what the correct solution should be, but what I'd try to > > do here is to move every function that just considers the platform > > rather than the architecture somewhere into drivers/hv where it > > can be linked into the same modules as the existing files when > > building for arm64, while trying to keep architecture specific code > > in the header file where it can be included from those modules. > > OK. The concept of separating platform from architecture makes > sense to me. The original separation of the Hyper-V code into > architecture independent portions and x86-specific portions could > use some tweaking now that we're dealing with n=2 architectures. With > that tweaking, I can reduce the amount of Hyper-V code under arch/x86 > and under arch/arm64. > > On the flip side, the Hyper-V implementation on x86 and ARM64 has > differences that are semi-related to the architecture. For example, on > x86 Hyper-V uses synthetic MSRs for a lot of guest-hypervisor setup, while > hypercalls are required on ARM64. So I'm assuming those differences > will end up in code under arch/x86 and arch/arm64. Yes, that absolutely makes sense. > Arguably, I could introduce a level of indirection (such as > CONFIG_HYPERV_USE_MSRS vs. > CONFIG_HYPERV_USE_HYPERCALLS) to distinguish the two behaviors. > The selection would be tied to the architecture, and then code in > drivers/hv can #ifdef the two cases. But I wonder if getting code out of > arch/x86 and arch/arm64 is worth that additional messiness. No, I think that would take it a little too far, and conflicts with the generic rule that code under drivers/* should be written to be portable even if can only run on a particular target platform. > Looking at the Xen code in drivers/xen, it looks like a lot of the Xen functionality > is implemented in hypercalls that can be consistent across architectures, > though I was a bit surprised to see a dozen or so instances of #ifdef CONFIG_X86. > Xen also #ifdefs on PV vs. PVHVM, which may handle some architecture > differences implicitly. But I'm assuming that doing #ifdef > in the Hyper-V code in order to reduce code under arch/x86 or arch/arm64 > is not the right way to go. In general that is true, adding a lot of #ifdefs makes code less readable and harder to test. OTOH there are cases where a single #ifdef can be useful when it avoids adding a larger amount of complexity elsewhere. Many subsystems try to restrict the #ifdef checks to header files while keeping the drivers/* code free of them. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel