linux-kernel - Re: [PATCH v7 07/10] arm64: hyperv: Initialize hypervisor on boot

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a3fzXuyamf=sokW59=Ln-ULBBGaSHxKwUeqxT_4sNrQqw@mail.gmail.com>
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