[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y0ctKrMAmX8WvWRA@google.com>
Date: Wed, 12 Oct 2022 21:10:02 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: isaku.yamahata@...el.com
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
isaku.yamahata@...il.com, Kai Huang <kai.huang@...el.com>,
Chao Gao <chao.gao@...el.com>,
Atish Patra <atishp@...shpatra.org>,
Shaokun Zhang <zhangshaokun@...ilicon.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Huang Ying <ying.huang@...el.com>,
Huacai Chen <chenhuacai@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v5 17/30] KVM: Move out KVM arch PM hooks and hardware
enable/disable logic
On Thu, Sep 22, 2022, isaku.yamahata@...el.com wrote:
> From: Isaku Yamahata <isaku.yamahata@...el.com>
>
> To make clear that those files are default implementation
Heh, this is debatable, I was quite confused/surprised by seeing kvm_arch.c. It's
also incomplete, which is further confusing, since there are a lot of default hooks
that are left behind. And we most definitely don't want to move all of them, since
many of those hooks are pure nops, i.e. get completely compiled out.
Given that we want this code to go away sooner than later, I don't think adding
a temporarily to-be-deleted file makes sense.
Powered by blists - more mailing lists