From: Arnd Bergmann <arnd@arndb.de> To: Michael Kelley <mikelley@microsoft.com> Cc: Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, "Mark.Rutland@arm.com" <Mark.Rutland@arm.com>, Marc Zyngier <maz@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, gregkh <gregkh@linuxfoundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, "wei.liu@kernel.org" <wei.liu@kernel.org>, vkuznets <vkuznets@redhat.com>, KY Srinivasan <kys@microsoft.com>, Sunil Muthuswamy <sunilmut@microsoft.com>, Boqun Feng <boqun.feng@gmail.com> Subject: Re: [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer Date: Wed, 26 Aug 2020 09:14:39 +0200 [thread overview] Message-ID: <CAK8P3a0bCf7Fe5Ex=AHUM49UuvNk0KEpXJ3jgWmULa2eDOWBKA@mail.gmail.com> (raw) In-Reply-To: <MW2PR2101MB105201EF9EB186AA9BF31A74D7570@MW2PR2101MB1052.namprd21.prod.outlook.com> On Wed, Aug 26, 2020 at 12:04 AM Michael Kelley <mikelley@microsoft.com> wrote: > From: Arnd Bergmann <arnd@arndb.de> 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 <architecture> > 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
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: Michael Kelley <mikelley@microsoft.com> Cc: "Mark.Rutland@arm.com" <Mark.Rutland@arm.com>, linux-arch <linux-arch@vger.kernel.org>, "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, gregkh <gregkh@linuxfoundation.org>, Catalin Marinas <catalin.marinas@arm.com>, Boqun Feng <boqun.feng@gmail.com>, Sunil Muthuswamy <sunilmut@microsoft.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "wei.liu@kernel.org" <wei.liu@kernel.org>, Marc Zyngier <maz@kernel.org>, vkuznets <vkuznets@redhat.com>, KY Srinivasan <kys@microsoft.com>, Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer Date: Wed, 26 Aug 2020 09:14:39 +0200 [thread overview] Message-ID: <CAK8P3a0bCf7Fe5Ex=AHUM49UuvNk0KEpXJ3jgWmULa2eDOWBKA@mail.gmail.com> (raw) In-Reply-To: <MW2PR2101MB105201EF9EB186AA9BF31A74D7570@MW2PR2101MB1052.namprd21.prod.outlook.com> On Wed, Aug 26, 2020 at 12:04 AM Michael Kelley <mikelley@microsoft.com> wrote: > From: Arnd Bergmann <arnd@arndb.de> 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 <architecture> > 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
next prev parent reply other threads:[~2020-08-26 7:15 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-24 16:46 [PATCH v7 00/10] Enable Linux guests on Hyper-V on ARM64 Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 16:46 ` [PATCH v7 01/10] arm/arm64: smccc-1.1: Add vendor specific owner definition Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 16:46 ` [PATCH v7 02/10] arm64: hyperv: Add core Hyper-V include files Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 18:38 ` Arnd Bergmann 2020-08-24 18:38 ` Arnd Bergmann 2020-08-24 16:46 ` [PATCH v7 03/10] arm64: hyperv: Add hypercall and register access functions Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 16:46 ` [PATCH v7 04/10] arm64: hyperv: Add memory alloc/free functions for Hyper-V size pages Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 16:46 ` [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 18:54 ` Arnd Bergmann 2020-08-24 18:54 ` Arnd Bergmann 2020-08-25 22:04 ` Michael Kelley 2020-08-25 22:04 ` Michael Kelley 2020-08-26 7:14 ` Arnd Bergmann [this message] 2020-08-26 7:14 ` Arnd Bergmann 2020-08-24 16:46 ` [PATCH v7 06/10] arm64: hyperv: Add kexec and panic handlers Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 16:46 ` [PATCH v7 07/10] arm64: hyperv: Initialize hypervisor on boot Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 18:33 ` Arnd Bergmann 2020-08-24 18:33 ` Arnd Bergmann 2020-08-25 21:20 ` Michael Kelley 2020-08-25 21:20 ` Michael Kelley 2020-08-26 7:18 ` Arnd Bergmann 2020-08-26 7:18 ` Arnd Bergmann 2020-08-24 16:46 ` [PATCH v7 08/10] Drivers: hv: vmbus: Add hooks for per-CPU IRQ Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 16:46 ` [PATCH v7 09/10] arm64: efi: Export screen_info Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 17:21 ` Ard Biesheuvel 2020-08-24 17:21 ` Ard Biesheuvel 2020-08-24 17:35 ` Greg KH 2020-08-24 17:35 ` Greg KH 2020-08-24 17:40 ` Michael Kelley 2020-08-24 17:40 ` Michael Kelley 2020-08-24 17:52 ` Greg KH 2020-08-24 17:52 ` Greg KH 2020-08-24 16:46 ` [PATCH v7 10/10] Drivers: hv: Enable Hyper-V code to be built on ARM64 Michael Kelley 2020-08-24 16:46 ` Michael Kelley 2020-08-24 17:24 ` Ard Biesheuvel 2020-08-24 17:24 ` Ard Biesheuvel 2020-08-24 17:28 ` Michael Kelley 2020-08-24 17:28 ` Michael Kelley 2020-08-25 8:47 ` Ben Dooks 2020-08-25 8:47 ` Ben Dooks
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAK8P3a0bCf7Fe5Ex=AHUM49UuvNk0KEpXJ3jgWmULa2eDOWBKA@mail.gmail.com' \ --to=arnd@arndb.de \ --cc=Mark.Rutland@arm.com \ --cc=ardb@kernel.org \ --cc=boqun.feng@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=kys@microsoft.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-hyperv@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maz@kernel.org \ --cc=mikelley@microsoft.com \ --cc=sunilmut@microsoft.com \ --cc=vkuznets@redhat.com \ --cc=wei.liu@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.