On Fri, 14 Feb 2020 11:24:39 -0500
Eric Farman <farman@xxxxxxxxxxxxx> wrote:
> On 2/14/20 8:34 AM, Cornelia Huck wrote:
> > On Thu, 6 Feb 2020 22:38:23 +0100
> > Eric Farman <farman@xxxxxxxxxxxxx> wrote:
> > (...)
> >> +static void vfio_ccw_alloc_crw(struct vfio_ccw_private *private,
> >> + struct chp_link *link,
> >> + unsigned int erc)
> >> +{
> >> + struct vfio_ccw_crw *vc_crw;
> >> + struct crw *crw;
> >> +
> >> + /*
> >> + * If unable to allocate a CRW, just drop the event and
> >> + * carry on. The guest will either see a later one or
> >> + * learn when it issues its own store subchannel.
> >> + */
> >> + vc_crw = kzalloc(sizeof(*vc_crw), GFP_ATOMIC);
> >> + if (!vc_crw)
> >> + return;
> >> +
> >> + /*
> >> + * Build in the first CRW space, but don't chain anything
> >> + * into the second one even though the space exists.
> >> + */
> >> + crw = &vc_crw->crw[0];
> >> +
> >> + /*
> >> + * Presume every CRW we handle is reported by a channel-path.
> >> + * Maybe not future-proof, but good for what we're doing now.
> >
> > You could pass in a source indication, maybe? Presumably, at least one
> > of the callers further up the chain knows...
>
> The "chain" is the vfio_ccw_chp_event() function called off the
> .chp_event callback, and then to this point. So I don't think there's
> much we can get back from our callchain, other than the CHP_xxxLINE
> event that got us here.
We might want to pass in CRW_RSC_CPATH, that would make it a bit more
flexible. We can easily rearrange code internally later, though.
