On 09/12/2022 09:56, David Woodhouse wrote:
From: Joao Martins <joao.m.mart...@oracle.com>
This means handling the new exit reason for Xen but still
crashing on purpose. As we implement each of the hypercalls
we will then return the right return code.
Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
[dwmw2: Add CPL to hypercall tracing, disallow hypercalls from CPL > 0]
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
target/i386/kvm/kvm.c | 5 +++++
target/i386/trace-events | 3 +++
target/i386/xen.c | 39 +++++++++++++++++++++++++++++++++++++++
target/i386/xen.h | 1 +
4 files changed, 48 insertions(+)
[snip]
+int kvm_xen_handle_exit(X86CPU *cpu, struct kvm_xen_exit *exit)
+{
+ if (exit->type != KVM_EXIT_XEN_HCALL)
+ return -1;
+
+ if (!__kvm_xen_handle_exit(cpu, exit)) {
+ /* Some hypercalls will be deliberately "implemented" by returning
+ * -ENOSYS. This case is for hypercalls which are unexpected. */
+ exit->u.hcall.result = -ENOSYS;
+ qemu_log_mask(LOG_GUEST_ERROR, "Unimplemented Xen hypercall %"
+ PRId64 " (0x%" PRIx64 " 0x%" PRIx64 " 0x%" PRIx64 ")\n",
+ (uint64_t)exit->u.hcall.input,
(uint64_t)exit->u.hcall.params[0],
+ (uint64_t)exit->u.hcall.params[1],
(uint64_t)exit->u.hcall.params[1]);
This could get a little noisy; would a trace not be better? Then only
those interested in it need be bothered by it. As we know, some ancient
guests attempt to use some hypercalls which have long been consigned to
the waste-bin of history.
Paul
+ }
+
+ trace_kvm_xen_hypercall(CPU(cpu)->cpu_index, exit->u.hcall.cpl,
+ exit->u.hcall.input, exit->u.hcall.params[0],
+ exit->u.hcall.params[1], exit->u.hcall.params[2],
+ exit->u.hcall.result);
+ return 0;
+}
