lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Aug 2020 09:18:53 +0200 From: Arnd Bergmann <arnd@...db.de> To: Michael Kelley <mikelley@...rosoft.com> Cc: Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, Catalin Marinas <catalin.marinas@....com>, "Mark.Rutland@....com" <Mark.Rutland@....com>, Marc Zyngier <maz@...nel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, gregkh <gregkh@...uxfoundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>, linux-efi <linux-efi@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>, "wei.liu@...nel.org" <wei.liu@...nel.org>, vkuznets <vkuznets@...hat.com>, KY Srinivasan <kys@...rosoft.com>, Sunil Muthuswamy <sunilmut@...rosoft.com>, Boqun Feng <boqun.feng@...il.com> Subject: Re: [PATCH v7 07/10] arm64: hyperv: Initialize hypervisor on boot On Tue, Aug 25, 2020 at 11:20 PM Michael Kelley <mikelley@...rosoft.com> wrote: > From: Arnd Bergmann <arnd@...db.de> Sent: Monday, August 24, 2020 11:34 AM > > On Mon, Aug 24, 2020 at 6:48 PM Michael Kelley <mikelley@...rosoft.com> wrote: > > > > I think this has come up before, and I still don't consider it an acceptable > > hack to hook platform initialization code into the timer code. > > > > Please split out the timer into a standalone driver in drivers/clocksource > > that can get reviewed by the clocksource maintainers. > > I see two related topics here. Agreed > First, the Hyper-V clocksource driver is > drivers/clocksource/hyperv_timer.c. The code is architecture independent > and is used today on the x86 side and for ARM64 in this patch series. A few > architecture specific calls are satisfied by code under arch/x86, and in this > patch series, under arch/arm64. Is there some aspect of this driver that > needs reconsideration? I just want to make sure to understand what you > are getting at. For the clocksource driver, I would like to see the arm64 specific bits (the code you add in arch/arm64 that are only relevant to this driver) moved out of arch/arm64 and into drivers/clocksource, in whatever form the clocksource maintainers prefer. I would suggest having a separate file that can get linked along with the architecture-independent part of that driver. > Second is the question of where/how to do Hyper-V specific initialization. > I agree that hanging it off the timer initialization isn't a great approach. > Should I add a Hyper-V specific initialization call at the appropriate point > in the ARM64 init sequence? The x86 side has some structure for handling > multiple hypervisors, and the Hyper-V initialization code naturally plugs into > that structure. I'm certainly open to suggestions on the best way to handle > it for ARM64. Yes, that is where I was getting at. Maybe the x86 abstraction for handling multiple hypervisors can be lifted out of arch/x86/ into common code? Arnd
Powered by blists - more mailing lists