Re: [PATCH 1/2] LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path

Re: [PATCH 1/2] LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path

[Bibo Mao]

On 2026/7/23 下午7:15, Zeng Chi wrote:
> From: Zeng Chi <zengchi@kylinos.cn>
> 
> In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
> kvm_complete_mmio_read() already advances the guest PC via update_pc().
> The explicit update_pc() call right after it advances the PC a second
> time, so PC moves forward by 8 instead of 4 and the instruction
> following the MMIO read is silently skipped.
> 
> The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run()
> calls kvm_complete_mmio_read() only once, and the MMIO write fast path
> advances the PC exactly once as well.
> 
> Remove the redundant update_pc() so the kernel MMIO read fast path
> advances the PC by a single instruction.
> 
> Fixes: 80edf90831a2 ("LoongArch: KVM: Add sign extension with kernel MMIO read emulation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
> ---
>   arch/loongarch/kvm/exit.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/loongarch/kvm/exit.c b/arch/loongarch/kvm/exit.c
> index 8572b63478bb..482ba17bcd3d 100644
> --- a/arch/loongarch/kvm/exit.c
> +++ b/arch/loongarch/kvm/exit.c
> @@ -481,7 +481,6 @@ int kvm_emu_mmio_read(struct kvm_vcpu *vcpu, larch_inst inst)
>   		srcu_read_unlock(&vcpu->kvm->srcu, idx);
>   		if (!ret) {
>   			kvm_complete_mmio_read(vcpu, run);
> -			update_pc(&vcpu->arch);
>   			vcpu->mmio_needed = 0;
>   			return EMULATE_DONE;
>   		}
> 
Hi Zeng,

Thanks for finding this problem, it is a big critical potential issue :(

Reviewed-by: Bibo Mao <maobibo@loongson.cn>

Re: [PATCH 1/2] LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path

[Tao Cui]

From: Tao Cui <cuitao@kylinos.cn>

> In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
> kvm_complete_mmio_read() already advances the guest PC via update_pc().
> The explicit update_pc() call right after it advances the PC a second
> time, so PC moves forward by 8 instead of 4 and the instruction
> following the MMIO read is silently skipped.

Good catch!
Reviewed-by: Tao Cui <cuitao@kylinos.cn>

Re: [PATCH 1/2] LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path

[Huacai Chen]

On Sat, Jul 25, 2026 at 11:38 AM Tao Cui <cui.tao@linux.dev> wrote:
>
> From: Tao Cui <cuitao@kylinos.cn>
>
> > In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
> > kvm_complete_mmio_read() already advances the guest PC via update_pc().
> > The explicit update_pc() call right after it advances the PC a second
> > time, so PC moves forward by 8 instead of 4 and the instruction
> > following the MMIO read is silently skipped.
>
> Good catch!
> Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Applied, thanks.

Huacai

Re: [PATCH 1/2] LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path

[Kaiyang Wu]

On 2026-07-23 19:15, Zeng Chi wrote:

> In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
> kvm_complete_mmio_read() already advances the guest PC via update_pc().
> The explicit update_pc() call right after it advances the PC a second
> time, so PC moves forward by 8 instead of 4 and the instruction
> following the MMIO read is silently skipped.
> 
> The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run()
> calls kvm_complete_mmio_read() only once, and the MMIO write fast path
> advances the PC exactly once as well.
> 
> Remove the redundant update_pc() so the kernel MMIO read fast path
> advances the PC by a single instruction.

Hi Zeng,

I have tested the patch on Proxmox VE with the environment below:

- CPU: Loongson 3C6000/D
- OS: Proxmox VE 9.2.11 (LoongArch port https://github.com/pve-loong64-port)
- Kernel: 7.0.14-15-pve
- Guest OS: Kylin Linux Advanced Server V10 (SP3 2403)
- Guest Kernel: 4.19.90-89.45.v2401.a.ky10.loongarch64

Without the patch, the guest system could not boot with the 
4.19.90-89.45.v2401.a.ky10.loongarch64 kernel and there was no output in 
neither tty nor serial. I can confirm the system boots from the same 
kernel version with the patch applied to the host kernel.

Best,
Kaiyang

Re: [PATCH 1/2] LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path

[Tao Cui]

Hi, Kaiyang

在 2026/9/2 18:12, Kaiyang Wu 写道:
> On 2026-07-23 19:15, Zeng Chi wrote:
> 
>> In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
>> kvm_complete_mmio_read() already advances the guest PC via update_pc().
>> The explicit update_pc() call right after it advances the PC a second
>> time, so PC moves forward by 8 instead of 4 and the instruction
>> following the MMIO read is silently skipped.
>>
>> The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run()
>> calls kvm_complete_mmio_read() only once, and the MMIO write fast path
>> advances the PC exactly once as well.
>>
>> Remove the redundant update_pc() so the kernel MMIO read fast path
>> advances the PC by a single instruction.
> 
> Hi Zeng,
> 
> I have tested the patch on Proxmox VE with the environment below:
> 
> - CPU: Loongson 3C6000/D
> - OS: Proxmox VE 9.2.11 (LoongArch port https://github.com/pve-loong64-port)
> - Kernel: 7.0.14-15-pve
> - Guest OS: Kylin Linux Advanced Server V10 (SP3 2403)
> - Guest Kernel: 4.19.90-89.45.v2401.a.ky10.loongarch64
> 
> Without the patch, the guest system could not boot with the 4.19.90-89.45.v2401.a.ky10.loongarch64 kernel and there was no output in neither tty nor serial. I can confirm the system boots from the same kernel version with the patch applied to the host kernel.
> 

Thank you for the testing, this is really helpful.

Our test setup is a bit different: we were running a 7.x kernel on
both the host and the guest, and we confirmed the issue by observing
that the PC advanced by the wrong step after an MMIO read.

Your result is a nice complement to ours — it suggests the same issue
may also explain the boot failure of a 4.19 guest on a 7.x host. We
had been debugging this boot failure for a while without finding the
root cause, and had assumed it was some kind of version
incompatibility. Your testing gives us a good lead to look into.

Thanks again for sharing your results.

--
Tao> Best,
> Kaiyang