| Message ID | 20230602161921.208564-3-amoorthy@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Improve scalability of KVM + userfaultfd live migration via annotated memory faults. | expand |
On Fri, Jun 02, 2023 at 04:19:07PM +0000, Anish Moorthy <amoorthy@google.com> wrote: > Give kvm_run.exit_reason a defined initial value on entry into KVM_RUN: > other architectures (riscv, arm64) already use KVM_EXIT_UNKNOWN for this > purpose, so copy that convention. > > This gives vCPUs trying to fill the run struct a mechanism to avoid > overwriting already-populated data, albeit an imperfect one. Being able > to detect an already-populated KVM run struct will prevent at least some > bugs in the upcoming implementation of KVM_CAP_MEMORY_FAULT_INFO, which > will attempt to fill the run struct whenever a vCPU fails a guest memory > access. > > Without the already-populated check, KVM_CAP_MEMORY_FAULT_INFO could > change kvm_run in any code paths which > > 1. Populate kvm_run for some exit and prepare to return to userspace > 2. Access guest memory for some reason (but without returning -EFAULTs > to userspace) > 3. Finish the return to userspace set up in (1), now with the contents > of kvm_run changed to contain efault info. > As vmx code uses KVM_EXIT_UNKNOWN with hardware_exit_reason=exit reason, Can we initialize hardware_exit_reason to -1. It's just in case. > Signed-off-by: Anish Moorthy <amoorthy@google.com> > --- > arch/x86/kvm/x86.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index ceb7c5e9cf9e..a7725d41570a 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -11163,6 +11163,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > if (r <= 0) > goto out; > > + kvm_run->exit_reason = KVM_EXIT_UNKNOWN; + kvm_run->hardware_exit_reason = -1; /* unused exit reason value */ > r = vcpu_run(vcpu); > > out: > -- > 2.41.0.rc0.172.g3f132b7071-goog >
On Fri, Jun 2, 2023 at 1:30 PM Isaku Yamahata <isaku.yamahata@gmail.com> wrote: > > As vmx code uses KVM_EXIT_UNKNOWN with hardware_exit_reason=exit reason, > Can we initialize hardware_exit_reason to -1. > It's just in case. Will do
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ceb7c5e9cf9e..a7725d41570a 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11163,6 +11163,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) if (r <= 0) goto out; + kvm_run->exit_reason = KVM_EXIT_UNKNOWN; r = vcpu_run(vcpu); out:
Give kvm_run.exit_reason a defined initial value on entry into KVM_RUN: other architectures (riscv, arm64) already use KVM_EXIT_UNKNOWN for this purpose, so copy that convention. This gives vCPUs trying to fill the run struct a mechanism to avoid overwriting already-populated data, albeit an imperfect one. Being able to detect an already-populated KVM run struct will prevent at least some bugs in the upcoming implementation of KVM_CAP_MEMORY_FAULT_INFO, which will attempt to fill the run struct whenever a vCPU fails a guest memory access. Without the already-populated check, KVM_CAP_MEMORY_FAULT_INFO could change kvm_run in any code paths which 1. Populate kvm_run for some exit and prepare to return to userspace 2. Access guest memory for some reason (but without returning -EFAULTs to userspace) 3. Finish the return to userspace set up in (1), now with the contents of kvm_run changed to contain efault info. Signed-off-by: Anish Moorthy <amoorthy@google.com> --- arch/x86/kvm/x86.c | 1 + 1 file changed, 1 insertion(+)