Thread (9 messages) 9 messages, 2 authors, 2021-10-16

Re: [PATCH 0/5] KVM: arm64: Reorganise vcpu first run

From: Marc Zyngier <maz@kernel.org>
Date: 2021-10-16 10:51:21
Also in: kvm, kvmarm

On Fri, 15 Oct 2021 11:05:48 +0100,
Andrew Jones [off-list ref] wrote:
On Fri, Oct 15, 2021 at 11:49:00AM +0200, Andrew Jones wrote:
quoted
On Fri, Oct 15, 2021 at 10:08:17AM +0100, Marc Zyngier wrote:
quoted
KVM/arm64 relies heavily on a bunch of things to be done on the first
run of the vcpu. We also do a bunch of things on PID change. It turns
out that these two things are pretty similar (the first PID change is
also the first run).

This small series aims at simplifying all that, and to get rid of the
vcpu->arch.has_run_once state.

Marc Zyngier (5):
  KVM: arm64: Move SVE state mapping at HYP to finalize-time
  KVM: arm64: Move kvm_arch_vcpu_run_pid_change() out of line
  KVM: arm64: Merge kvm_arch_vcpu_run_pid_change() and
    kvm_vcpu_first_run_init()
  KVM: arm64: Restructure the point where has_run_once is advertised
Maybe do the restructuring before the merging in order to avoid the
potential for bizarre states?
Yup, can do.
Also, before we do the merge I think we need to duplicate the

        if (unlikely(!kvm_vcpu_initialized(vcpu)))
                return -ENOEXEC;

that we currently have above the call of kvm_vcpu_first_run_init()
into kvm_arch_vcpu_run_pid_change() because
kvm_arch_vcpu_run_pid_change() is called before kvm_arch_vcpu_ioctl_run()
in KVM_RUN.
Well spotted.

I think this check should be moved into kvm_arch_vcpu_run_pid_change()
instead of duplicated though, just like we have the check for
'finalized' there. After all, they are the two sides of the same coin.

This nicely moves all checks on the slow path.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help