On Mon, May 19, 2025 at 5:55 PM Radim Krčmář <rkrcmar@xxxxxxxxxxxxxxxx> wrote: > > 2025-05-16T17:55:05+05:30, Anup Patel <anup@xxxxxxxxxxxxxx>: > > On Thu, May 15, 2025 at 8:22 PM Radim Krčmář <rkrcmar@xxxxxxxxxxxxxxxx> wrote: > >> > >> Add a toggleable VM capability to reset the VCPU from userspace by > >> setting MP_STATE_INIT_RECEIVED through IOCTL. > >> > >> Reset through a mp_state to avoid adding a new IOCTL. > >> Do not reset on a transition from STOPPED to RUNNABLE, because it's > >> better to avoid side effects that would complicate userspace adoption. > >> The MP_STATE_INIT_RECEIVED is not a permanent mp_state -- IOCTL resets > >> the VCPU while preserving the original mp_state -- because we wouldn't > >> gain much from having a new state it in the rest of KVM, but it's a very > >> non-standard use of the IOCTL. > >> > >> Signed-off-by: Radim Krčmář <rkrcmar@xxxxxxxxxxxxxxxx> > >> --- > >> If we want a permanent mp_state, I think that MP_STATE_UNINITIALIZED > >> would be reasonable. KVM could reset on transition to any other state. > > > > Yes, MP_STATE_UNINITIALIZED looks better. I also suggest > > that VCPU should be reset when set_mpstate() is called with > > MP_STATE_UNINITIALIZED and the current state is > > MP_STATE_STOPPED. > > That would result in two resets (stopped -> uninitialized -> *), unless > we changed the logic. > > Would you prefer to reset on transition to the new permanent mp_state? > MP_STATE_INIT_RECEIVED seems a more fitting name for the state, then. > Let's not introduce unnecessary state transitions and go ahead with MP_STATE_INIT_RECEIVED Reviewed-by: Anup Patel <anup@xxxxxxxxxxxxxx> Queued this patch for Linux-6.16 Thanks, Anup
