Re: [RFC PATCH v2 10/22] i386/xen: handle guest hypercalls

[David Woodhouse]

On Mon, 2022-12-12 at 14:11 +0000, Paul Durrant wrote:
> On 09/12/2022 09:56, David Woodhouse wrote:
> > From: Joao Martins <
> > joao.m.martins@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.martins@oracle.com
> > >
> > [dwmw2: Add CPL to hypercall tracing, disallow hypercalls from CPL > 0]
> > Signed-off-by: David Woodhouse <
> > dwmw@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.

By the time I'm done here, qemu is going to get the benefit of all
those things that "we know", and is going to have implementations of
those ancient hypercalls which intentionally return -ENOSYS and don't
trigger this warning.

So this is worth reporting in *addition* to the trace (which does also
exist). I'll change it to LOG_UNIMP though, as I think I mentioned in
the cover message.

smime.p7s
Description: S/MIME cryptographic signature