linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sgoel@codeaurora.org (Goel, Sameer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: kexec: Add machine_kexec_mask_interrupts to kexec path
Date: Fri, 20 Apr 2018 17:39:01 -0600	[thread overview]
Message-ID: <9132cbb9-6288-a6d5-3acb-f50527c84b90@codeaurora.org> (raw)
In-Reply-To: <20180420102332.kzxyn6lpe2ernnrg@lakrids.cambridge.arm.com>



On 4/20/2018 4:23 AM, Mark Rutland wrote:
> Hi Sameer,
> 
> On Wed, Apr 18, 2018 at 08:19:36PM -0600, Sameer Goel wrote:
>> In kdump code path SPIs at GIC level are explicitly cleared by
>> calling machine_kexec_mask_interrupts. In case of kexec this
>> functionality is delegated for most part to the device shutdown
>> functions.
>> Add machine_kexec_mask_interrupts to machine_shutdown path to
>> ensure that the irqs are masked at the gic level.
> 
> I think that for kdump, the plan is to try to get irqchips to reset
> things in their probe paths (e.g. as that's the sanest place to poke
> APRn). Doing that would render machine_kexec_mask_interrupts() redundant
> for kexec.
I agree the above proposed change in GIC will make machine_kexec_mask_interrupts() redundant. Can you please point me to the change if already posted.
> 
>> Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
>> ---
>> Porting code for masking irqs at gic from kdump shutdown to kexec path.
>>
>> There was discussion about this functionality in [1].
>>
>> [1] https://patchwork.kernel.org/patch/9817499/
> 
> I don't follow why this is a problem. Nate mentions corrupting the new
> kernel -- has a problem been observed in practice?
> 
> The purgatory code is run with IRQs masked at the CPU, and the new
> kernel will initialise the GIC before enabling interrupts at the CPU.
> Once probed, the SMMU driver can handle spurious interrupts.
> 
> So AFAICT there is no problem today. Am I missing something?

This was something that was proposed when the driver owners were not clearing interrupts in their shutdown functions. So, more of a cleanup. From you description above it makes sense.

Thanks,
Sameer
> 
> When could an interrupt be taken that would be problematic?
> 
> Currently, I don't see that this is necessary. Given we'd like to remove
> machine_kexec_mask_interrupts() for the kdump case, I'd prefer that we
> don't mandate it in the usual kexec case.
> 
> Thanks,
> Mark.
> 
>>
>>  arch/arm64/include/asm/kexec.h    | 6 ++++++
>>  arch/arm64/kernel/machine_kexec.c | 2 +-
>>  arch/arm64/kernel/process.c       | 2 ++
>>  3 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>> index e17f052..f9ddb41 100644
>> --- a/arch/arm64/include/asm/kexec.h
>> +++ b/arch/arm64/include/asm/kexec.h
>> @@ -93,6 +93,12 @@ static inline void crash_prepare_suspend(void) {}
>>  static inline void crash_post_resume(void) {}
>>  #endif
>>  
>> +#if defined(CONFIG_KEXEC)
>> +extern void machine_kexec_mask_interrupts(void);
>> +#else
>> +static inline void machine_kexec_mask_interrupts(void) {}
>> +#endif
>> +
>>  #endif /* __ASSEMBLY__ */
>>  
>>  #endif
>> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
>> index f76ea92..b453180 100644
>> --- a/arch/arm64/kernel/machine_kexec.c
>> +++ b/arch/arm64/kernel/machine_kexec.c
>> @@ -213,7 +213,7 @@ void machine_kexec(struct kimage *kimage)
>>  	BUG(); /* Should never get here. */
>>  }
>>  
>> -static void machine_kexec_mask_interrupts(void)
>> +void machine_kexec_mask_interrupts(void)
>>  {
>>  	unsigned int i;
>>  	struct irq_desc *desc;
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index f08a2ed..9d0337e 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -58,6 +58,7 @@
>>  #include <asm/mmu_context.h>
>>  #include <asm/processor.h>
>>  #include <asm/stacktrace.h>
>> +#include <asm/kexec.h>
>>  
>>  #ifdef CONFIG_CC_STACKPROTECTOR
>>  #include <linux/stackprotector.h>
>> @@ -107,6 +108,7 @@ void arch_cpu_idle_dead(void)
>>  void machine_shutdown(void)
>>  {
>>  	disable_nonboot_cpus();
>> +	machine_kexec_mask_interrupts();
>>  }
>>  
>>  /*
>> -- 
>> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

      reply	other threads:[~2018-04-20 23:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19  2:19 [PATCH] arm64: kexec: Add machine_kexec_mask_interrupts to kexec path Sameer Goel
2018-04-20  5:00 ` AKASHI Takahiro
2018-04-20 10:23 ` Mark Rutland
2018-04-20 23:39   ` Goel, Sameer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9132cbb9-6288-a6d5-3acb-f50527c84b90@codeaurora.org \
    --to=sgoel@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).