| Message ID | 20231027182217.3615211-19-seanjc@google.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | KVM: guest_memfd() and per-page attributes | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/vmtest-fixes-PR | fail | merge-conflict |
On 10/27/23 20:22, Sean Christopherson wrote: > Initialize run->exit_reason to KVM_EXIT_UNKNOWN early in KVM_RUN to reduce > the probability of exiting to userspace with a stale run->exit_reason that > *appears* to be valid. > > To support fd-based guest memory (guest memory without a corresponding > userspace virtual address), KVM will exit to userspace for various memory > related errors, which userspace *may* be able to resolve, instead of using > e.g. BUS_MCEERR_AR. And in the more distant future, KVM will also likely > utilize the same functionality to let userspace "intercept" and handle > memory faults when the userspace mapping is missing, i.e. when fast gup() > fails. > > Because many of KVM's internal APIs related to guest memory use '0' to > indicate "success, continue on" and not "exit to userspace", reporting > memory faults/errors to userspace will set run->exit_reason and > corresponding fields in the run structure fields in conjunction with a > a non-zero, negative return code, e.g. -EFAULT or -EHWPOISON. And because > KVM already returns -EFAULT in many paths, there's a relatively high > probability that KVM could return -EFAULT without setting run->exit_reason, > in which case reporting KVM_EXIT_UNKNOWN is much better than reporting > whatever exit reason happened to be in the run structure. > > Note, KVM must wait until after run->immediate_exit is serviced to > sanitize run->exit_reason as KVM's ABI is that run->exit_reason is > preserved across KVM_RUN when run->immediate_exit is true. > > Link: https://lore.kernel.org/all/20230908222905.1321305-1-amoorthy@google.com > Link: https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > Signed-off-by: Sean Christopherson <seanjc@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 ee3cd8c3c0ef..f41dbb1465a0 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -10963,6 +10963,7 @@ static int vcpu_run(struct kvm_vcpu *vcpu) > { > int r; > > + vcpu->run->exit_reason = KVM_EXIT_UNKNOWN; > vcpu->arch.l1tf_flush_l1d = true; > > for (;;) { Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
On Fri, Oct 27, 2023 at 7:23 PM Sean Christopherson <seanjc@google.com> wrote: > > Initialize run->exit_reason to KVM_EXIT_UNKNOWN early in KVM_RUN to reduce > the probability of exiting to userspace with a stale run->exit_reason that > *appears* to be valid. > > To support fd-based guest memory (guest memory without a corresponding > userspace virtual address), KVM will exit to userspace for various memory > related errors, which userspace *may* be able to resolve, instead of using > e.g. BUS_MCEERR_AR. And in the more distant future, KVM will also likely > utilize the same functionality to let userspace "intercept" and handle > memory faults when the userspace mapping is missing, i.e. when fast gup() > fails. > > Because many of KVM's internal APIs related to guest memory use '0' to > indicate "success, continue on" and not "exit to userspace", reporting > memory faults/errors to userspace will set run->exit_reason and > corresponding fields in the run structure fields in conjunction with a > a non-zero, negative return code, e.g. -EFAULT or -EHWPOISON. And because > KVM already returns -EFAULT in many paths, there's a relatively high > probability that KVM could return -EFAULT without setting run->exit_reason, > in which case reporting KVM_EXIT_UNKNOWN is much better than reporting > whatever exit reason happened to be in the run structure. > > Note, KVM must wait until after run->immediate_exit is serviced to > sanitize run->exit_reason as KVM's ABI is that run->exit_reason is > preserved across KVM_RUN when run->immediate_exit is true. > > Link: https://lore.kernel.org/all/20230908222905.1321305-1-amoorthy@google.com > Link: https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Cheers, /fuad > 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 ee3cd8c3c0ef..f41dbb1465a0 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -10963,6 +10963,7 @@ static int vcpu_run(struct kvm_vcpu *vcpu) > { > int r; > > + vcpu->run->exit_reason = KVM_EXIT_UNKNOWN; > vcpu->arch.l1tf_flush_l1d = true; > > for (;;) { > -- > 2.42.0.820.g83a721a137-goog >
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ee3cd8c3c0ef..f41dbb1465a0 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10963,6 +10963,7 @@ static int vcpu_run(struct kvm_vcpu *vcpu) { int r; + vcpu->run->exit_reason = KVM_EXIT_UNKNOWN; vcpu->arch.l1tf_flush_l1d = true; for (;;) {
Initialize run->exit_reason to KVM_EXIT_UNKNOWN early in KVM_RUN to reduce the probability of exiting to userspace with a stale run->exit_reason that *appears* to be valid. To support fd-based guest memory (guest memory without a corresponding userspace virtual address), KVM will exit to userspace for various memory related errors, which userspace *may* be able to resolve, instead of using e.g. BUS_MCEERR_AR. And in the more distant future, KVM will also likely utilize the same functionality to let userspace "intercept" and handle memory faults when the userspace mapping is missing, i.e. when fast gup() fails. Because many of KVM's internal APIs related to guest memory use '0' to indicate "success, continue on" and not "exit to userspace", reporting memory faults/errors to userspace will set run->exit_reason and corresponding fields in the run structure fields in conjunction with a a non-zero, negative return code, e.g. -EFAULT or -EHWPOISON. And because KVM already returns -EFAULT in many paths, there's a relatively high probability that KVM could return -EFAULT without setting run->exit_reason, in which case reporting KVM_EXIT_UNKNOWN is much better than reporting whatever exit reason happened to be in the run structure. Note, KVM must wait until after run->immediate_exit is serviced to sanitize run->exit_reason as KVM's ABI is that run->exit_reason is preserved across KVM_RUN when run->immediate_exit is true. Link: https://lore.kernel.org/all/20230908222905.1321305-1-amoorthy@google.com Link: https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/x86.c | 1 + 1 file changed, 1 insertion(+)