Steven Price [off-list ref] writes:
+
+ switch (rec->run->exit.exit_reason) {
+ case RMI_EXIT_SYNC:
+ /*
+ * HPFAR_EL2_NS is hijacked to indicate a valid HPFAR value,
+ * see __get_fault_info()
+ */
+ vcpu->arch.fault.hpfar_el2 = rec->run->exit.hpfar | HPFAR_EL2_NS;
+ rec_exit_sync(vcpu);
+ return ARM_EXCEPTION_TRAP;
+ case RMI_EXIT_IRQ:
+ case RMI_EXIT_FIQ:
+ return ARM_EXCEPTION_IRQ;
+ case RMI_EXIT_SERROR:
+ return ARM_EXCEPTION_EL1_SERROR;
+ case RMI_EXIT_PSCI:
+ rec_exit_hvc(vcpu);
+ kvm_make_request(KVM_REQ_RMI, vcpu);
I'm also wondering whether we can move the kvm_make_request() call until
after the PSCI/HOST_CALL handling is complete. I tried a quick hack, but
it did not look particularly clean, since we would end up adding
RMM-specific checks in handle_hvc():
ret = kvm_smccc_call_handler(vcpu);
if (vcpu_is_rec(vcpu) &&
(vcpu->arch.rec.run->exit.exit_reason == RMI_EXIT_PSCI ||
vcpu->arch.rec.run->exit.exit_reason == RMI_EXIT_HOST_CALL))
kvm_make_request(KVM_REQ_RMI, vcpu);
That said, having rec_exit_hvc(vcpu) and kvm_make_request() back-to-back
is also somewhat confusing. Perhaps we could at least add a comment
explaining why the request must always be made here.
+ return ARM_EXCEPTION_TRAP;
+ case RMI_EXIT_RIPAS_CHANGE:
+ rec_exit_hvc(vcpu);
+ return ARM_EXCEPTION_TRAP;
+ }
+
+ return rec_exit_fatal(vcpu, "Unsupported Realm exit reason",
+ rec->run->exit.exit_reason);
+}
-aneesh