Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 01 Sep 2022 10:03:16 +0100
Message-ID: <87y1v3v54b.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Sean Christopherson <seanjc@google.com>
Cc:     "Huang, Kai" <kai.huang@intel.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Yamahata, Isaku" <isaku.yamahata@intel.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "Shahar, Sagi" <sagis@google.com>,
        "Aktas, Erdem" <erdemaktas@google.com>,
        "isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>,
        Will Deacon <will@kernel.org>
Subject: Re: [PATCH v8 003/103] KVM: Refactor CPU compatibility check on module initialization
In-Reply-To: <YvU+6fdkHaqQiKxp@google.com>
References: <cover.1659854790.git.isaku.yamahata@intel.com>
        <4092a37d18f377003c6aebd9ced1280b0536c529.1659854790.git.isaku.yamahata@intel.com>
        <d36802ee3d96d0fdac00d2c11be341f94a362ef9.camel@intel.com>
        <YvU+6fdkHaqQiKxp@google.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

Sean,

On Thu, 11 Aug 2022 18:39:53 +0100,
Sean Christopherson <seanjc@google.com> wrote:
> 
> +Will (for arm crud)

When it comes to KVM/arm64, I'd appreciate if you could Cc me.

> arm64 is also quite evil and circumvents KVM's hardware enabling
> logic to some extent.  kvm_arch_init() => init_subsystems()
> unconditionally enables hardware, and for pKVM _leaves_ hardware
> enabled.  And then hyp_init_cpu_pm_notifier() disables/enables
> hardware across lower power enter+exit, except if pKVM is enabled.
> The icing on the cake is "disabling" hardware doesn't even do
> anything (AFAICT) if the kernel is running at EL2 (which I think is
> nVHE + not-pKVM?).

In the cases where disabling doesn't do anything (which are the exact
opposite of the cases you describe), that's because there is
absolutely *nothing* to do:

- If VHE, the kernel is the bloody hypervisor: disable virtualisation,
  kill the kernel.

- if pKVM, the kernel is basically a guest, and has no business
  touching anything at all.

So much the 'evil' behaviour.

	M.

-- 
Without deviation from the norm, progress is not possible.