Re: [PATCH v7 26/51] hw/xen: Add xen_evtchn device for event channel emulation

[David Woodhouse]

On Tue, 2023-01-17 at 11:06 +0000, Paul Durrant wrote:
> On 17/01/2023 11:02, David Woodhouse wrote:
> > On Tue, 2023-01-17 at 10:56 +0000, Paul Durrant wrote:
> > > 
> > > I'm just having a hard time seeing why passing 0 to
> > > xen_evtchn_set_callback_param() does anything useful...
> > > 
> > > +    switch (param >> CALLBACK_VIA_TYPE_SHIFT) {
> > > +    case HVM_PARAM_CALLBACK_TYPE_VECTOR: {
> > > +        struct kvm_xen_hvm_attr xa = {
> > > +            .type = KVM_XEN_ATTR_TYPE_UPCALL_VECTOR,
> > > +            .u.vector = (uint8_t)param,
> > > +        };
> > > 
> > > HVM_PARAM_CALLBACK_TYPE_VECTOR is 2 AFAICT, so it won't hit that
> > > case.
> > > Also, you appear to be passing the unshifted param to kernel
> > > anyway.
> > > 
> > > What is the call trying to achieve?
> > 
> > Zero is HVM_PARAM_CALLBACK_TYPE_GSI, with GSI==0. It's basically
> > disabling event channel delivery for the new kernel.
> > 
> 
> AFAICT it is doing nothing at this point. Unless I am going insane it
> results in this codepath:
> 
> +    default:
> +        ret = -ENOSYS;
> +        break;
> +    }
> +
> +    if (!ret) {
> +        s->callback_param = param;
> +        s->evtchn_in_kernel = in_kernel;
> +    }
> 
> So it doesn't result in any cleanup. What am I missing?

Indeed, it doesn't result in any cleanup at *this* point in the series
because HVM_PARAM_CALLBACK_TYPE_GSI hasn't been implemented yet; it's
in a later patch.

The series is broken up into sensible individual patches for review,
not so people can actually *run* with some partial subset of them.

Otherwise I'd have to implement vmstate migration versioning for every
change in the series, and that way lies madness :)

I *will* add a comment in the code explaining what zero means though,
and note in the commit message that it doesn't actually have any effect
will, but will do in a few patches' time.

smime.p7s
Description: S/MIME cryptographic signature