[PATCH 0/2] Dump instructions on panic for pKVM/nvhe

[PATCH 0/2] Dump instructions on panic for pKVM/nvhe

[Mostafa Saleh]

This small series, adds support for dumping the faulting instructions on
panic in pKVM and nvhe, similarly to what the kernel does as follow:
[   12.012126] kvm [190]: nVHE hyp BUG at: [<ffff8000811c5f64>] __kvm_nvhe_handle___kvm_vcpu_run+0x4/0x8!
[   12.015747] kvm [190]: Cannot dump pKVM nVHE stacktrace: !CONFIG_PROTECTED_NVHE_STACKTRACE
[   12.016044] Code: a8c17bfd d50323bf d65f03c0 d503245f (d4210000)
[   12.016082] kvm [190]: Hyp Offset: 0xffeff6887fe00000
[   12.016325] Kernel panic - not syncing: HYP panic:
[   12.016325] PS:204023c9 PC:000f8978013c5f64 ESR:00000000f2000800
[   12.016325] FAR:fff00000c016e01c HPFAR:00000000010016e0 PAR:0000000000000000

This can be useful in debugging cases of memory corruption.

The first patch adds this for nvhe and CONFIG_NVHE_EL2_DEBUG which is
straightforward as at the point of panic there is no stage-2 for the
host CPU, so it can re-use the kernel code to read and dump the faulting
instructions.

The second patch adds this support for pKVM, I splitted that into patches
as the pKVM changes are more fundamental, as now the hypervisor text would
be mapped in the host stage-2 as RO all the time.
An alternative is to make the hypervisor read its instructions on panic and
passes it to the kernel panic handler, but as we are out of registers
(X0-X7 used) for the arguments we would have to move that code to assembly.


Mostafa Saleh (2):
  KVM: arm64: Dump instruction on hyp panic
  KVM: arm64: Map hyp text as RO and dump instr on panic

 arch/arm64/include/asm/traps.h  |  1 +
 arch/arm64/kernel/traps.c       | 20 +++++++++++++-------
 arch/arm64/kvm/handle_exit.c    |  3 +++
 arch/arm64/kvm/hyp/nvhe/setup.c | 12 ++++++++++--
 4 files changed, 27 insertions(+), 9 deletions(-)

-- 
2.50.0.727.gbf7dc18ff4-goog

[PATCH 1/2] KVM: arm64: Dump instruction on hyp panic

[Mostafa Saleh]

Similar to the kernel panic, where the instruction code is printed,
we can do the same for hypervisor panics.

This patch does that only in case of “CONFIG_NVHE_EL2_DEBUG” or nvhe.

The next patch adds support for pKVM.

Also, remove the hardcoded argument dump_kernel_instr().

Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
 arch/arm64/include/asm/traps.h |  1 +
 arch/arm64/kernel/traps.c      | 20 +++++++++++++-------
 arch/arm64/kvm/handle_exit.c   |  5 +++++
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index 82cf1f879c61..0d7e86a95d62 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -30,6 +30,7 @@ void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *
 void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
 
 int early_brk64(unsigned long addr, unsigned long esr, struct pt_regs *regs);
+void dump_instr(unsigned long addr);
 
 /*
  * Move regs->pc to next instruction and do necessary setup before it
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 9bfa5c944379..d692c05e3686 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -149,15 +149,11 @@ pstate_check_t * const aarch32_opcode_cond_checks[16] = {
 
 int show_unhandled_signals = 0;
 
-static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
+void dump_instr(unsigned long addr)
 {
-	unsigned long addr = instruction_pointer(regs);
 	char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str;
 	int i;
 
-	if (user_mode(regs))
-		return;
-
 	for (i = -4; i < 1; i++) {
 		unsigned int val, bad;
 
@@ -169,7 +165,17 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
 			p += sprintf(p, i == 0 ? "(????????) " : "???????? ");
 	}
 
-	printk("%sCode: %s\n", lvl, str);
+	printk(KERN_EMERG "Code: %s\n", str);
+}
+
+static void dump_kernel_instr(struct pt_regs *regs)
+{
+	unsigned long addr = instruction_pointer(regs);
+
+	if (user_mode(regs))
+		return;
+
+	dump_instr(addr);
 }
 
 #define S_SMP " SMP"
@@ -190,7 +196,7 @@ static int __die(const char *str, long err, struct pt_regs *regs)
 	print_modules();
 	show_regs(regs);
 
-	dump_kernel_instr(KERN_EMERG, regs);
+	dump_kernel_instr(regs);
 
 	return ret;
 }
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 453266c96481..de12b4d4bccd 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -565,6 +565,11 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 	/* Dump the nVHE hypervisor backtrace */
 	kvm_nvhe_dump_backtrace(hyp_offset);
 
+	/* Dump the faulting instruction */
+	if (!is_protected_kvm_enabled() ||
+	    IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
+		dump_instr(panic_addr + kaslr_offset());
+
 	/*
 	 * Hyp has panicked and we're going to handle that by panicking the
 	 * kernel. The kernel offset will be revealed in the panic so we're
-- 
2.50.0.727.gbf7dc18ff4-goog

Re: [PATCH 1/2] KVM: arm64: Dump instruction on hyp panic

[Kunwu Chan]

Hi Mostafa,
On 2025/7/18 07:47, Mostafa Saleh wrote:

... ....

> +	/* Dump the faulting instruction */
> +	if (!is_protected_kvm_enabled() ||
> +	    IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
> +		dump_instr(panic_addr + kaslr_offset());
> +
This part seem like unnecessary, cause it'll be remove in patch 2(Only 
the comment left).

>   	/*
>   	 * Hyp has panicked and we're going to handle that by panicking the
>   	 * kernel. The kernel offset will be revealed in the panic so we're
Another confusion is that no similar wording to what you mentioned in 
the cover—specifically "Cannot dump pKVM nVHE stacktrace: 
!CONFIG_PROTECTED_NVHE_STACKTRACE"—has been found in the code.


-- 
Thanks,
        Kunwu Chan.

Re: [PATCH 1/2] KVM: arm64: Dump instruction on hyp panic

[Mostafa Saleh]

Hi Kunwu,

On Thu, Jul 31, 2025 at 1:59 PM Kunwu Chan <kunwu.chan@linux.dev> wrote:
>
> Hi Mostafa,
> On 2025/7/18 07:47, Mostafa Saleh wrote:
>
> ... ....
>
> > +     /* Dump the faulting instruction */
> > +     if (!is_protected_kvm_enabled() ||
> > +         IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
> > +             dump_instr(panic_addr + kaslr_offset());
> > +
> This part seem like unnecessary, cause it'll be remove in patch 2(Only
> the comment left).
>

Yes, the idea is that the first patch adds that only for CONFIG_NVHE_EL2_DEBUG
while the second does that for all configs, I split it this way as
doing that with stage-2
requires intrusive changes, so at least this patch can be picked
separately if needed.

> >       /*
> >        * Hyp has panicked and we're going to handle that by panicking the
> >        * kernel. The kernel offset will be revealed in the panic so we're
> Another confusion is that no similar wording to what you mentioned in
> the cover—specifically "Cannot dump pKVM nVHE stacktrace:
> !CONFIG_PROTECTED_NVHE_STACKTRACE"—has been found in the code.
>
I am not sure I follow, this has nothing to do with
"CONFIG_PROTECTED_NVHE_STACKTRACE"
This series added the print for for instructions as:
[   12.016044] Code: a8c17bfd d50323bf d65f03c0 d503245f (d4210000)

All other prints are from already existing code.

Thanks,
Mostafa


>
> --
> Thanks,
>         Kunwu Chan.
>

Re: [PATCH 1/2] KVM: arm64: Dump instruction on hyp panic

[Kunwu Chan]

Hi Mostafa,

On 2025/7/31 21:05, Mostafa Saleh wrote:
> Hi Kunwu,
>
> On Thu, Jul 31, 2025 at 1:59 PM Kunwu Chan <kunwu.chan@linux.dev> wrote:
>> Hi Mostafa,
>> On 2025/7/18 07:47, Mostafa Saleh wrote:
>>
>> ... ....
>>
>>> +     /* Dump the faulting instruction */
>>> +     if (!is_protected_kvm_enabled() ||
>>> +         IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
>>> +             dump_instr(panic_addr + kaslr_offset());
>>> +
>> This part seem like unnecessary, cause it'll be remove in patch 2(Only
>> the comment left).
>>
> Yes, the idea is that the first patch adds that only for CONFIG_NVHE_EL2_DEBUG
> while the second does that for all configs, I split it this way as
> doing that with stage-2
> requires intrusive changes, so at least this patch can be picked
> separately if needed.
>
>>>        /*
>>>         * Hyp has panicked and we're going to handle that by panicking the
>>>         * kernel. The kernel offset will be revealed in the panic so we're
>> Another confusion is that no similar wording to what you mentioned in
>> the cover—specifically "Cannot dump pKVM nVHE stacktrace:
>> !CONFIG_PROTECTED_NVHE_STACKTRACE"—has been found in the code.
>>
> I am not sure I follow, this has nothing to do with
> "CONFIG_PROTECTED_NVHE_STACKTRACE"
> This series added the print for for instructions as:
> [   12.016044] Code: a8c17bfd d50323bf d65f03c0 d503245f (d4210000)
>
> All other prints are from already existing code.

Got it—I see what happened now. Turns out the confusion was caused

  by my CONFIG_PROTECTED_NVHE_STACKTRACE being enabled.

After turning that off and testing Patch 1 standalone, everything works 
exactly as you described.

The test results:

1: disable CONFIG_NVHE_EL2_DEBUG

--> "kvm [5375]: Hyp Offset: 0xfffec95693400000"

2: enable CONFIG_NVHE_EL2_DEBUG

--> "[ 684.715883][ T5525] Code: d51d991f d51d9901 d5159001 00000000 
(d4210000)

                   [ 684.715974][ T5525] kvm [5525]: Hyp Offset: 
0xfffe992b13400000"

3: without this patch :

--> "kvm [5497]: Hyp Offset: 0xfffedd4993400000"

Thanks for the clarification—really appreciate your help!

>
> Thanks,
> Mostafa


Feel free to add :

Tested-by: Kunwu Chan <chentao@kylinos.cn>
Reviewed-by: Kunwu Chan <chentao@kylinos.cn>


-- 
Thanks,
        Kunwu Chan.

[PATCH 2/2] KVM: arm64: Map hyp text as RO and dump instr on panic

[Mostafa Saleh]

Map the hyp text section as RO, there are no secrets there
and that allows the kernel extract info for debugging.

As in case of panic we can now dump the faulting instructions
similar to the kernel.

Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
 arch/arm64/kvm/handle_exit.c    |  4 +---
 arch/arm64/kvm/hyp/nvhe/setup.c | 12 ++++++++++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index de12b4d4bccd..d59f33c40767 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -566,9 +566,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 	kvm_nvhe_dump_backtrace(hyp_offset);
 
 	/* Dump the faulting instruction */
-	if (!is_protected_kvm_enabled() ||
-	    IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
-		dump_instr(panic_addr + kaslr_offset());
+	dump_instr(panic_addr + kaslr_offset());
 
 	/*
 	 * Hyp has panicked and we're going to handle that by panicking the
diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
index a48d3f5a5afb..90bd014e952f 100644
--- a/arch/arm64/kvm/hyp/nvhe/setup.c
+++ b/arch/arm64/kvm/hyp/nvhe/setup.c
@@ -192,6 +192,7 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
 	enum pkvm_page_state state;
 	struct hyp_page *page;
 	phys_addr_t phys;
+	enum kvm_pgtable_prot prot;
 
 	if (!kvm_pte_valid(ctx->old))
 		return 0;
@@ -210,11 +211,18 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
 	 * configured in the hypervisor stage-1, and make sure to propagate them
 	 * to the hyp_vmemmap state.
 	 */
-	state = pkvm_getstate(kvm_pgtable_hyp_pte_prot(ctx->old));
+	prot = kvm_pgtable_hyp_pte_prot(ctx->old);
+	state = pkvm_getstate(prot);
 	switch (state) {
 	case PKVM_PAGE_OWNED:
 		set_hyp_state(page, PKVM_PAGE_OWNED);
-		return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
+		/* hyp text is RO in the host stage-2 to be inspected on panic. */
+		if (prot == PAGE_HYP_EXEC) {
+			set_host_state(page, PKVM_NOPAGE);
+			return host_stage2_idmap_locked(phys, PAGE_SIZE, KVM_PGTABLE_PROT_R);
+		} else {
+			return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
+		}
 	case PKVM_PAGE_SHARED_OWNED:
 		set_hyp_state(page, PKVM_PAGE_SHARED_OWNED);
 		set_host_state(page, PKVM_PAGE_SHARED_BORROWED);
-- 
2.50.0.727.gbf7dc18ff4-goog

Re: [PATCH 2/2] KVM: arm64: Map hyp text as RO and dump instr on panic

[Ben Horgan]

Hi Mostafa,

On 18/07/2025 00:47, Mostafa Saleh wrote:
> Map the hyp text section as RO, there are no secrets there
> and that allows the kernel extract info for debugging.
> 
> As in case of panic we can now dump the faulting instructions
> similar to the kernel.
> 
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
>   arch/arm64/kvm/handle_exit.c    |  4 +---
>   arch/arm64/kvm/hyp/nvhe/setup.c | 12 ++++++++++--
>   2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index de12b4d4bccd..d59f33c40767 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -566,9 +566,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
>   	kvm_nvhe_dump_backtrace(hyp_offset);
>   
>   	/* Dump the faulting instruction */
> -	if (!is_protected_kvm_enabled() ||
> -	    IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
> -		dump_instr(panic_addr + kaslr_offset());
> +	dump_instr(panic_addr + kaslr_offset());
This makes the dumping in nvhe no longer conditional on 
CONFIG_NVHE_EL2_DEBUG. A change from what you introduced in the patch. 
Perhaps it makes sense to reorder the patches; do the preparatory work 
for instruction dumping before the enabling.>
>   	/*
>   	 * Hyp has panicked and we're going to handle that by panicking the
> diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> index a48d3f5a5afb..90bd014e952f 100644
> --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> @@ -192,6 +192,7 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
>   	enum pkvm_page_state state;
>   	struct hyp_page *page;
>   	phys_addr_t phys;
> +	enum kvm_pgtable_prot prot;
>   
>   	if (!kvm_pte_valid(ctx->old))
>   		return 0;
> @@ -210,11 +211,18 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
>   	 * configured in the hypervisor stage-1, and make sure to propagate them
>   	 * to the hyp_vmemmap state.
>   	 */
> -	state = pkvm_getstate(kvm_pgtable_hyp_pte_prot(ctx->old));
> +	prot = kvm_pgtable_hyp_pte_prot(ctx->old);
> +	state = pkvm_getstate(prot);
>   	switch (state) {
>   	case PKVM_PAGE_OWNED:
>   		set_hyp_state(page, PKVM_PAGE_OWNED);
> -		return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
> +		/* hyp text is RO in the host stage-2 to be inspected on panic. */
> +		if (prot == PAGE_HYP_EXEC) {
> +			set_host_state(page, PKVM_NOPAGE);
> +			return host_stage2_idmap_locked(phys, PAGE_SIZE, KVM_PGTABLE_PROT_R);
> +		} else {
> +			return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
> +		}
>   	case PKVM_PAGE_SHARED_OWNED:
>   		set_hyp_state(page, PKVM_PAGE_SHARED_OWNED);
>   		set_host_state(page, PKVM_PAGE_SHARED_BORROWED);
-- 
Thanks,

Ben

Re: [PATCH 2/2] KVM: arm64: Map hyp text as RO and dump instr on panic

[Mostafa Saleh]

Hi Ben,

On Fri, Jul 18, 2025 at 11:16:18AM +0100, Ben Horgan wrote:
> Hi Mostafa,
> 
> On 18/07/2025 00:47, Mostafa Saleh wrote:
> > Map the hyp text section as RO, there are no secrets there
> > and that allows the kernel extract info for debugging.
> > 
> > As in case of panic we can now dump the faulting instructions
> > similar to the kernel.
> > 
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> >   arch/arm64/kvm/handle_exit.c    |  4 +---
> >   arch/arm64/kvm/hyp/nvhe/setup.c | 12 ++++++++++--
> >   2 files changed, 11 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> > index de12b4d4bccd..d59f33c40767 100644
> > --- a/arch/arm64/kvm/handle_exit.c
> > +++ b/arch/arm64/kvm/handle_exit.c
> > @@ -566,9 +566,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
> >   	kvm_nvhe_dump_backtrace(hyp_offset);
> >   	/* Dump the faulting instruction */
> > -	if (!is_protected_kvm_enabled() ||
> > -	    IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
> > -		dump_instr(panic_addr + kaslr_offset());
> > +	dump_instr(panic_addr + kaslr_offset());
> This makes the dumping in nvhe no longer conditional on
> CONFIG_NVHE_EL2_DEBUG. A change from what you introduced in the patch.
> Perhaps it makes sense to reorder the patches; do the preparatory work for
> instruction dumping before the enabling.>

Yes, I thought about squashing both patches, but I was worried this patch
might be more controversial, so I split the code into 2 patches, where the
first one can be merged separately if needed. But no strong opinion.

Thanks,
Mostafa

> >   	/*
> >   	 * Hyp has panicked and we're going to handle that by panicking the
> > diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> > index a48d3f5a5afb..90bd014e952f 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> > @@ -192,6 +192,7 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
> >   	enum pkvm_page_state state;
> >   	struct hyp_page *page;
> >   	phys_addr_t phys;
> > +	enum kvm_pgtable_prot prot;
> >   	if (!kvm_pte_valid(ctx->old))
> >   		return 0;
> > @@ -210,11 +211,18 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
> >   	 * configured in the hypervisor stage-1, and make sure to propagate them
> >   	 * to the hyp_vmemmap state.
> >   	 */
> > -	state = pkvm_getstate(kvm_pgtable_hyp_pte_prot(ctx->old));
> > +	prot = kvm_pgtable_hyp_pte_prot(ctx->old);
> > +	state = pkvm_getstate(prot);
> >   	switch (state) {
> >   	case PKVM_PAGE_OWNED:
> >   		set_hyp_state(page, PKVM_PAGE_OWNED);
> > -		return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
> > +		/* hyp text is RO in the host stage-2 to be inspected on panic. */
> > +		if (prot == PAGE_HYP_EXEC) {
> > +			set_host_state(page, PKVM_NOPAGE);
> > +			return host_stage2_idmap_locked(phys, PAGE_SIZE, KVM_PGTABLE_PROT_R);
> > +		} else {
> > +			return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
> > +		}
> >   	case PKVM_PAGE_SHARED_OWNED:
> >   		set_hyp_state(page, PKVM_PAGE_SHARED_OWNED);
> >   		set_host_state(page, PKVM_PAGE_SHARED_BORROWED);
> -- 
> Thanks,
> 
> Ben
> 

Re: [PATCH 2/2] KVM: arm64: Map hyp text as RO and dump instr on panic

[Ben Horgan]

Hi Mostafa,

On 18/07/2025 11:22, Mostafa Saleh wrote:
> Hi Ben,
> 
> On Fri, Jul 18, 2025 at 11:16:18AM +0100, Ben Horgan wrote:
>> Hi Mostafa,
>>
>> On 18/07/2025 00:47, Mostafa Saleh wrote:
>>> Map the hyp text section as RO, there are no secrets there
>>> and that allows the kernel extract info for debugging.
>>>
>>> As in case of panic we can now dump the faulting instructions
>>> similar to the kernel.
>>>
>>> Signed-off-by: Mostafa Saleh <smostafa@google.com>
>>> ---
>>>    arch/arm64/kvm/handle_exit.c    |  4 +---
>>>    arch/arm64/kvm/hyp/nvhe/setup.c | 12 ++++++++++--
>>>    2 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>>> index de12b4d4bccd..d59f33c40767 100644
>>> --- a/arch/arm64/kvm/handle_exit.c
>>> +++ b/arch/arm64/kvm/handle_exit.c
>>> @@ -566,9 +566,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
>>>    	kvm_nvhe_dump_backtrace(hyp_offset);
>>>    	/* Dump the faulting instruction */
>>> -	if (!is_protected_kvm_enabled() ||
>>> -	    IS_ENABLED(CONFIG_NVHE_EL2_DEBUG))
>>> -		dump_instr(panic_addr + kaslr_offset());
>>> +	dump_instr(panic_addr + kaslr_offset());
>> This makes the dumping in nvhe no longer conditional on
>> CONFIG_NVHE_EL2_DEBUG. A change from what you introduced in the patch.
>> Perhaps it makes sense to reorder the patches; do the preparatory work for
>> instruction dumping before the enabling.>
> 
> Yes, I thought about squashing both patches, but I was worried this patch
> might be more controversial, so I split the code into 2 patches, where the
> first one can be merged separately if needed. But no strong opinion.

My concern was you were changing the non-pkvm case too in this patch but 
I see now that you weren't. Sorry, my mistake. I'm ok with this patch 
split.>
> Thanks,
> Mostafa
> 
>>>    	/*
>>>    	 * Hyp has panicked and we're going to handle that by panicking the
>>> diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
>>> index a48d3f5a5afb..90bd014e952f 100644
>>> --- a/arch/arm64/kvm/hyp/nvhe/setup.c
>>> +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
>>> @@ -192,6 +192,7 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
>>>    	enum pkvm_page_state state;
>>>    	struct hyp_page *page;
>>>    	phys_addr_t phys;
>>> +	enum kvm_pgtable_prot prot;
>>>    	if (!kvm_pte_valid(ctx->old))
>>>    		return 0;
>>> @@ -210,11 +211,18 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
>>>    	 * configured in the hypervisor stage-1, and make sure to propagate them
>>>    	 * to the hyp_vmemmap state.
>>>    	 */
>>> -	state = pkvm_getstate(kvm_pgtable_hyp_pte_prot(ctx->old));
>>> +	prot = kvm_pgtable_hyp_pte_prot(ctx->old);
>>> +	state = pkvm_getstate(prot);
>>>    	switch (state) {
>>>    	case PKVM_PAGE_OWNED:
>>>    		set_hyp_state(page, PKVM_PAGE_OWNED);
>>> -		return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
>>> +		/* hyp text is RO in the host stage-2 to be inspected on panic. */
>>> +		if (prot == PAGE_HYP_EXEC) {
>>> +			set_host_state(page, PKVM_NOPAGE);
>>> +			return host_stage2_idmap_locked(phys, PAGE_SIZE, KVM_PGTABLE_PROT_R);
>>> +		} else {
>>> +			return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
>>> +		}
>>>    	case PKVM_PAGE_SHARED_OWNED:
>>>    		set_hyp_state(page, PKVM_PAGE_SHARED_OWNED);
>>>    		set_host_state(page, PKVM_PAGE_SHARED_BORROWED);
>> -- 
>> Thanks,
>>
>> Ben
>>
Thanks,

Ben