[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <D9K1TVIG544A.DAEZQAFBUDB4@ventanamicro.com>
Date: Wed, 30 Apr 2025 16:38:57 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Anup Patel" <anup@...infault.org>
Cc: "Anup Patel" <apatel@...tanamicro.com>, <kvm-riscv@...ts.infradead.org>,
<kvm@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, "Atish Patra" <atishp@...shpatra.org>,
"Paul Walmsley" <paul.walmsley@...ive.com>, "Palmer Dabbelt"
<palmer@...belt.com>, "Albert Ou" <aou@...s.berkeley.edu>, "Alexandre
Ghiti" <alex@...ti.fr>, "Andrew Jones" <ajones@...tanamicro.com>, "Mayuresh
Chitale" <mchitale@...tanamicro.com>
Subject: Re: [PATCH 4/5] KVM: RISC-V: reset VCPU state when becoming
runnable
2025-04-30T18:32:31+05:30, Anup Patel <anup@...infault.org>:
> On Wed, Apr 30, 2025 at 5:15 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>> We can re-use KVM_SET_MP_STATE and add a KVM capability.
>> Userspace will opt-in to reset the VCPU through the existing IOCTL.
>>
>> This design will also allow userspace to trigger a VCPU reset without
>> tearing down the whole VM.
>
> Okay, lets go ahead with a KVM capability which user space can opt-in
> for KVM_SET_MP_STATE ioctl().
>
> Keep in mind that at runtime Guest can still do CPU hotplug using SBI
> HSM start/stop and do system suspend using SBI SUSP so we should
> continue to have VCPU reset requests for both these SBI extensions.
Will do, thanks.
Powered by blists - more mailing lists