[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7463da3b-1d52-40a4-97a3-4f912f4f9fdb@redhat.com>
Date: Tue, 28 Mar 2023 16:13:54 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Tianrui Zhao <zhaotianrui@...ngson.cn>
Cc: Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <kernel@...0n.name>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Mark Brown <broonie@...nel.org>,
Alex Deucher <alexander.deucher@....com>,
Oliver Upton <oliver.upton@...ux.dev>, maobibo@...ngson.cn,
Xi Ruoyao <xry111@...111.site>
Subject: Re: [PING PATCH v4 23/29] LoongArch: KVM: Implement handle gspr
exception
On 3/28/23 14:31, Tianrui Zhao wrote:
> + case 0xc91:
> + /* idle GSPR */
> + er = _kvm_emu_idle(vcpu);
> + break;
So this is my last remark. What some other architectures do is change
vcpu->arch.mp_state when entering an idle state, and at this point all
calls to KVM_RUN would call the equivalent of _kvm_emu_idle(). This
requires implementing the KVM_GET_MPSTATE and KVM_SET_MPSTATE ioctls.
This might also be useful if later you want to implement a mechanism
where vCPUs can pause or resume, for example for multi-vCPU VMs.
You can implement this on top of what you have, but I highly recommend
that you do it in the first version of what is committed to Linux.
Paolo
Powered by blists - more mailing lists