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

[David Woodhouse]

On Tue, 2023-01-17 at 11:53 +0000, Paul Durrant wrote:
> On 17/01/2023 11:24, David Woodhouse wrote:
> > 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.
> > 
> 
> That's fine. It's just confusing for a reviewer to know whether you are 
> intentionally introducing code that has no effect, or whether that is a bug.

Actually... it *is* a bug. Even when GSI support is added later,
nothing ever tells the kernel to *stop* delivering via the upcall
vector. I'll fix. Thanks for drawing attention to it.

smime.p7s
Description: S/MIME cryptographic signature