[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxC865e8sfEvp7Iw@google.com>
Date: Thu, 1 Sep 2022 14:08:43 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Marc Zyngier <maz@...nel.org>
Cc: "Huang, Kai" <kai.huang@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Shahar, Sagi" <sagis@...gle.com>,
"Aktas, Erdem" <erdemaktas@...gle.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
Will Deacon <will@...nel.org>
Subject: Re: [PATCH v8 003/103] KVM: Refactor CPU compatibility check on
module initialization
On Thu, Sep 01, 2022, Marc Zyngier wrote:
> Sean,
>
> On Thu, 11 Aug 2022 18:39:53 +0100,
> Sean Christopherson <seanjc@...gle.com> wrote:
> >
> > +Will (for arm crud)
>
> When it comes to KVM/arm64, I'd appreciate if you could Cc me.
Sorry, will do.
> > 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:
Yes, I know.
> - 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.
The colorful language is tongue-in-cheek.
I get the impression that you feel I am attacking ARM. That is very much not what
I intended. If anything, I'm attacking x86 for forcing its quirks on everyone else.
What am trying to point out here is that ARM and other architectures are not
well-served by KVM's current hardware enabling/disabling infrastructure. I am not
saying that ARM is broken and needs to be fixed, I am saying that KVM is broken and
needs to be fixed, and that ARM is a victim of KVM's x86-centric origins.
Powered by blists - more mailing lists