From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754752AbbDOMt2 (ORCPT ); Wed, 15 Apr 2015 08:49:28 -0400 Received: from foss.arm.com ([217.140.101.70]:35901 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752201AbbDOMtU (ORCPT ); Wed, 15 Apr 2015 08:49:20 -0400 Date: Wed, 15 Apr 2015 13:49:14 +0100 From: Mark Rutland To: AKASHI Takahiro Cc: Catalin Marinas , Will Deacon , Marc Zyngier , "christoffer.dall@linaro.org" , "geoff@infradead.org" , "broonie@kernel.org" , "david.griego@linaro.org" , "freddy77@gmail.com" , "kexec@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linaro-kernel@lists.linaro.org" , "linux-kernel@vger.kernel.org" Subject: Re: [v3 2/5] arm64: kvm: allow EL2 context to be reset on shutdown Message-ID: <20150415124913.GF2866@leverpostej> References: <1427953216-11737-1-git-send-email-takahiro.akashi@linaro.org> <1427953216-11737-3-git-send-email-takahiro.akashi@linaro.org> <20150408130520.GB5977@leverpostej> <552605CD.7000704@linaro.org> <20150409150244.GG9648@leverpostej> <55276A7E.1080508@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55276A7E.1080508@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > What I don't understand is why we can't move the init and tear-down > > functions into kvm_arch_hardware_enable/disable(). They seem to be for > > precisely what you are implementing, with the only difference being the > > time that they are called. > > I don't know, neither. I just followed the discussions between Marc and Geoff, > and their conclusion. I guessed that *refactoring* might be more complicated than > expected. > > FYI, I gave a quick try to kvm_arch_hardware_enable() approach by removing > cpu_init_hyp_mode() from init_hyp_mode() and putting it into kvm_arch_hardware_enable(), > and it seems to work, at least, in my environment: > boot => start a kvm guest => kexec reboot => start a kvm guest That sounds pretty convincing to me, assuming you wired the teardown intp kvm_arch_hardware_disable() ? > > Either I'm missing something, or we can simply implement the existing > > hooks. I assume I'm missing something. > > Marc, Geoff, any comments? > > > >>>> +static struct notifier_block kvm_reboot_nb = { > >>>> + .notifier_call = kvm_reboot_notify, > >>>> + .next = NULL, > >>>> + .priority = 0, /* FIXME */ > >>> > >>> It would be helpful for the comment to explain why this is wrong, and > >>> what needs fixing. > >> > >> Thank for reminding me of this. > >> > >> *priority* enforces a calling order of registered hook functions. > >> If some hook returns NOTIFY_STOP_MASK, subsequent hooks won't be called. > >> (Nevertheless, reboot sequence will go ahead. See kernel_restart_prepare()/ > >> notifier_call_chain().) > >> > >> So we should make sure that kvm_reboot_notify() be called > >> 1) after any hook functions which may depend on kvm, and > > > > Which hooks depend on KVM? > > I think I answered this question below: > >> But how can we guarantee this and determine a priority of kvm_reboot_notify()? > >> Looking into all the occurrences of register_reboot_notifier(), > >> 1) => nothing > >> 2) => virt/kvm/kvm_main.c (priority: 0) > >> 3) => drivers/cpufreq/s32416-cpufreq.c (priority: 0) > >> drivers/cpufreq/s5pv210-cpufreq.c (priority: 0) > >> > >> So a priority higher than zero might be safe and better, but exactly what? > >> Some hooks use "INT_MAX." I can't see anything listed which has a dependency on KVM. The KVM notifier would be superseded by kvm_arch_hardware_{disable,enable}, and the cpufreq instances don't seem to have any relationship to KVM. Other architectures use kvm_arch_hardware_{enable,disable}(), so I imagine the core KVM code has no problem with the ordering of these. Mark.