Re: [PATCH v5 3/5] LoongArch: KVM: Set default MAILBOX access size with 8

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Non-atomic read-modify-write of IPI mailbox in `mail_send()` and `send_ipi_data()` can lead to lost mailbox updates.
--

--- Patch [3]: [PATCH v5 3/5] LoongArch: KVM: Set default MAILBOX access size with 8 ---
commit 41b08f9f42313b6881c240343f238221b9928a3a
Author: Bibo Mao <maobibo@loongson.cn>

LoongArch: KVM: Set default MAILBOX access size with 8

This commit updates the IOCSR instruction emulation in KVM LoongArch.
It removes the explicit case for 8-byte lengths and instead uses the
default case to handle 8-byte access in the mailbox read and write
functions.

> diff --git a/arch/loongarch/kvm/intc/ipi.c b/arch/loongarch/kvm/intc/ipi.c
> index 928f9bd5e1f12..3871a6953a649 100644
> --- a/arch/loongarch/kvm/intc/ipi.c
> +++ b/arch/loongarch/kvm/intc/ipi.c

[ ... ]

> @@ -92,11 +89,9 @@ static void write_mailbox(struct kvm_vcpu *vcpu, int offset, uint64_t data, int
>  	case 4:
>  		*(unsigned int *)pbuf = (unsigned int)data;
>  		break;
> -	case 8:
> +	default:
>  		*(unsigned long *)pbuf = (unsigned long)data;
>  		break;
> -	default:
> -		kvm_err("%s: unknown data len: %d\n", __func__, len);
>  	}
>  	spin_unlock(&vcpu->arch.ipi_state.lock);
>  }

[Severity: High]
This is a pre-existing issue, but looking at how read_mailbox() and
write_mailbox() are used together, is there a potential race condition
when multiple vCPUs send IPIs concurrently?

In mail_send(), the read and write operations are performed independently:

arch/loongarch/kvm/intc/ipi.c:mail_send() {
    ...
    if ((data >> 27) & 0xf) {
        val = read_mailbox(vcpu, offset, 4);
        for (i = 0; i < 4; i++)
            if (data & (BIT(27 + i)))
                mask |= (0xff << (i * 8));
        val &= mask;
    }

    val |= ((uint32_t)(data >> 32) & ~mask);
    write_mailbox(vcpu, offset, val, 4);
    ...
}

Since ipi_state.lock is acquired and released inside both read_mailbox()
and write_mailbox(), could two sender vCPUs read the same initial state,
apply their masks, and write back, causing one of the updates to be lost?

A similar pattern appears in send_ipi_data(), where kvm_io_bus_read() and
kvm_io_bus_write() are used with the SRCU lock being dropped in between.

Could this lead to dropped IPI data and guest hangs under concurrent
workloads?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714072520.2745942-1-maobibo@loongson.cn?part=3