<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/arch/loongarch/kvm/timer.c, branch master</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2026-08-10T04:21:50+00:00</updated>
<entry>
<title>LoongArch: KVM: Prevent division by zero in periodic timer restore</title>
<updated>2026-08-10T04:21:50+00:00</updated>
<author>
<name>Tao Cui</name>
<email>cuitao@kylinos.cn</email>
</author>
<published>2026-08-10T04:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=01c823f14ed4caac4bf1ceb90926f26d67d753ec'/>
<id>urn:sha1:01c823f14ed4caac4bf1ceb90926f26d67d753ec</id>
<content type='text'>
A guest can write CSR.TCFG with the periodic bit set but a period value
of zero. When kvm_restore_timer() later enters the periodic branch,
period = cfg &amp; CSR_TCFG_VAL evaluates to 0, causing (delta % period) to
trigger a division by zero and crash the host kernel.

Clamp the period to 1 to avoid the panic.

Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Reviewed-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Tao Cui &lt;cuitao@kylinos.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Reload one-shot TVAL on migration destination</title>
<updated>2026-08-10T04:21:50+00:00</updated>
<author>
<name>Tao Cui</name>
<email>cuitao@kylinos.cn</email>
</author>
<published>2026-08-10T04:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=fe41c0759b11b982f945633b7abb4b49dfaf8ce4'/>
<id>urn:sha1:fe41c0759b11b982f945633b7abb4b49dfaf8ce4</id>
<content type='text'>
kvm_restore_timer() rebuilds the remaining timer countdown value from
vcpu-&gt;arch.expire, which is host-internal and is not part of the
migrated vCPU state. On the migration destination it is still 0, so for
a one-shot timer that has not expired yet the computed delta is 0 and
write_gcsr_timertick(0) injects the timer interrupt immediately instead
of after the remaining time.

The expired one-shot case (TVAL = -1) is already handled earlier. When
expire has not been set (i.e. on the migration destination), reload the
remaining countdown value from the migrated TVAL. This covers both one-
shot and periodic timers. The regular preempt/resume path on the source,
where expire is valid, is unchanged.

Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Suggested-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Reviewed-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Tao Cui &lt;cuitao@kylinos.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Remove timer interrupt injection when SW timer expired</title>
<updated>2026-06-11T12:46:43+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2026-06-11T12:46:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=83551ccedffda28b1fa7aeb8fcf5e00489443816'/>
<id>urn:sha1:83551ccedffda28b1fa7aeb8fcf5e00489443816</id>
<content type='text'>
The software timer emulation is to wake up vCPU when the vCPU executes
idle instruction and gives up host CPU, the vCPU timer tick value and
interrupt is set when vCPU is scheduled in.

It is not necessary to inject timer interrupt when SW timer is expired.
Here remove it, also use common API kvm_vcpu_wake_up() to wake up vCPU.

Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Move unconditional delay into timer clear scenery</title>
<updated>2026-05-04T01:00:48+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2026-05-04T01:00:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5a873d77ba792410a796595a917be6a440f9b7d2'/>
<id>urn:sha1:5a873d77ba792410a796595a917be6a440f9b7d2</id>
<content type='text'>
When timer interrupt arrives in guest kernel, guest kernel clears the
timer interrupt and program timer with the next incoming event.

During this stage, timer tick is -1 and timer interrupt status is
disabled in ESTAT register. KVM hypervisor need write zero with timer
tick register and wait timer interrupt injection from HW side, and
then clear timer interrupt.

So there is 2 cycle delay in KVM hypervisor to emulate such scenery,
and the delay is unnecessary if there is no need to clear the timer
interrupt.

Here move 2 cycle delay into timer clear scenery and add timer ESTAT
checking after delay, and set max timer expire value if timer interrupt
does not arrive still.

Cc: stable@vger.kernel.org
Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Add delay until timer interrupt injected</title>
<updated>2025-11-10T00:37:07+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2025-11-09T08:02:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=d3c9515e4f9d10ccb113adb4809db5cc31e7ef65'/>
<id>urn:sha1:d3c9515e4f9d10ccb113adb4809db5cc31e7ef65</id>
<content type='text'>
When timer is fired in oneshot mode, CSR.TVAL will stop with value -1
rather than 0. However when the register CSR.TVAL is restored, it will
continue to count down rather than stop there.

Now the method is to write 0 to CSR.TVAL, wait to count down for 1 cycle
at least, which is 10ns with a timer freq 100MHz, and then retore timer
interrupt status. Here add 2 cycles delay to assure that timer interrupt
is injected.

With this patch, timer selftest case passes to run always.

Cc: stable@vger.kernel.org
Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Mark hrtimer to expire in hard interrupt context</title>
<updated>2024-10-23T14:15:44+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhuacai@loongson.cn</email>
</author>
<published>2024-10-23T14:15:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=73adbd92f3223dc0c3506822b71c6b259d5d537b'/>
<id>urn:sha1:73adbd92f3223dc0c3506822b71c6b259d5d537b</id>
<content type='text'>
Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard
interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the
timer expire in hardirq context on RT"), On PREEMPT_RT enabled kernels
unmarked hrtimers are moved into soft interrupt expiry mode by default.
Then the timers are canceled from an preempt-notifier which is invoked
with disabled preemption which is not allowed on PREEMPT_RT.

The timer callback is short so in could be invoked in hard-IRQ context.
So let the timer expire on hard-IRQ context even on -RT.

This fix a "scheduling while atomic" bug for PREEMPT_RT enabled kernels:

 BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002
 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns
 CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G        W          6.12.0-rc2+ #1774
 Tainted: [W]=WARN
 Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022
 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000
         90000001167475a0 0000000000000000 90000001167475a8 9000000005644830
         90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001
         0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140
         00000000000003fe 0000000000000001 000000000000000d 0000000000000003
         0000000000000030 00000000000003f3 000000000790c000 9000000116747830
         90000000057ef000 0000000000000000 9000000005644830 0000000000000004
         0000000000000000 90000000057f4b58 0000000000000001 9000000116747868
         900000000451b600 9000000005644830 9000000003a13998 0000000010000020
         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d
         ...
 Call Trace:
 [&lt;9000000003a13998&gt;] show_stack+0x38/0x180
 [&lt;9000000004e3ea34&gt;] dump_stack_lvl+0x84/0xc0
 [&lt;9000000003a71708&gt;] __schedule_bug+0x48/0x60
 [&lt;9000000004e45734&gt;] __schedule+0x1114/0x1660
 [&lt;9000000004e46040&gt;] schedule_rtlock+0x20/0x60
 [&lt;9000000004e4e330&gt;] rtlock_slowlock_locked+0x3f0/0x10a0
 [&lt;9000000004e4f038&gt;] rt_spin_lock+0x58/0x80
 [&lt;9000000003b02d68&gt;] hrtimer_cancel_wait_running+0x68/0xc0
 [&lt;9000000003b02e30&gt;] hrtimer_cancel+0x70/0x80
 [&lt;ffff80000235eb70&gt;] kvm_restore_timer+0x50/0x1a0 [kvm]
 [&lt;ffff8000023616c8&gt;] kvm_arch_vcpu_load+0x68/0x2a0 [kvm]
 [&lt;ffff80000234c2d4&gt;] kvm_sched_in+0x34/0x60 [kvm]
 [&lt;9000000003a749a0&gt;] finish_task_switch.isra.0+0x140/0x2e0
 [&lt;9000000004e44a70&gt;] __schedule+0x450/0x1660
 [&lt;9000000004e45cb0&gt;] schedule+0x30/0x180
 [&lt;ffff800002354c70&gt;] kvm_vcpu_block+0x70/0x120 [kvm]
 [&lt;ffff800002354d80&gt;] kvm_vcpu_halt+0x60/0x3e0 [kvm]
 [&lt;ffff80000235b194&gt;] kvm_handle_gspr+0x3f4/0x4e0 [kvm]
 [&lt;ffff80000235f548&gt;] kvm_handle_exit+0x1c8/0x260 [kvm]

Reviewed-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Invalidate guest steal time address on vCPU reset</title>
<updated>2024-08-26T15:11:32+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2024-08-26T15:11:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=4956e07f05e239b274d042618a250c9fa3e92629'/>
<id>urn:sha1:4956e07f05e239b274d042618a250c9fa3e92629</id>
<content type='text'>
If ParaVirt steal time feature is enabled, there is a percpu gpa address
passed from guest vCPU and host modifies guest memory space with this gpa
address. When vCPU is reset normally, it will notify host and invalidate
gpa address.

However if VM is crashed and VMM reboots VM forcely, the vCPU reboot
notification callback will not be called in VM. Host needs invalidate
the gpa address, else host will modify guest memory during VM reboots.
Here it is invalidated from the vCPU KVM_REG_LOONGARCH_VCPU_RESET ioctl
interface.

Also funciton kvm_reset_timer() is removed at vCPU reset stage, since SW
emulated timer is only used in vCPU block state. When a vCPU is removed
from the block waiting queue, kvm_restore_timer() is called and SW timer
is cancelled. And the timer register is also cleared at VMM when a vCPU
is reset.

Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Do not restart SW timer when it is expired</title>
<updated>2024-03-06T01:12:13+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2024-03-06T01:12:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f66228053e429bd926505c447d3af2d3d610ed92'/>
<id>urn:sha1:f66228053e429bd926505c447d3af2d3d610ed92</id>
<content type='text'>
LoongArch VCPUs have their own separate HW timers. SW timer is to wake
up blocked vcpu thread, rather than HW timer emulation. When blocking
vcpu scheduled out, SW timer is used to wakeup blocked vcpu thread and
injects timer interrupt. It does not care about whether guest timer is
in period mode or oneshot mode, and SW timer needs not to be restarted
since vcpu has been woken.

This patch does not restart SW timer when it is expired.

Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Start SW timer only when vcpu is blocking</title>
<updated>2024-03-06T01:12:13+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2024-03-06T01:12:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=8bc15d02d5fdff31bfeca02e58e22e26880dde39'/>
<id>urn:sha1:8bc15d02d5fdff31bfeca02e58e22e26880dde39</id>
<content type='text'>
SW timer is enabled when vcpu thread is scheduled out, and it is to wake
up vcpu from blocked queue. If vcpu thread is scheduled out but is not
blocked, such as it is preempted by other threads, it is not necessary
to enable SW timer. Since vcpu thread is still on running queue if it is
preempted and SW timer is only to wake up vcpu on blocking queue, so SW
timer is not useful in this situation.

This patch enables SW timer only when vcpu is scheduled out and is
blocking.

Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: KVM: Fix timer emulation with oneshot mode</title>
<updated>2023-12-19T02:48:28+00:00</updated>
<author>
<name>Bibo Mao</name>
<email>maobibo@loongson.cn</email>
</author>
<published>2023-12-19T02:48:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5b3d524993ff1fb36089be850ccb121ac3296bcf'/>
<id>urn:sha1:5b3d524993ff1fb36089be850ccb121ac3296bcf</id>
<content type='text'>
When timer is fired in oneshot mode, CSR TVAL will be -1 rather than 0.
There needs special handing for this situation. There are two scenarios
when oneshot timer is fired. One scenario is that time is fired after
exiting to host, CSR TVAL is set with 0 in order to inject hw interrupt,
and -1 will assigned to CSR TVAL soon.

The other situation is that timer is fired in VM and guest kernel is
hanlding timer IRQ, IRQ is acked and is ready to set next expired timer
value, then vm exits to host. Timer interrupt should not be inject at
this point, else there will be spurious timer interrupt.

Here hw timer irq status in CSR ESTAT is used to judge these two
scenarios. If CSR TVAL is -1, the oneshot timer is fired; and if timer
hw irq is on in CSR ESTAT register, it happens after exiting to host;
else if timer hw irq is off, we think that it happens in vm and timer
IRQ handler has already acked IRQ.

With this patch, runltp with version ltp20230516 passes to run in vm.

Signed-off-by: Bibo Mao &lt;maobibo@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
</feed>
