On 3/24/20 12:34 PM, Cornelia Huck wrote:
> 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.
>
This is true... I'll rearrange it so the routine takes the rsid as
input instead of the link, as well as the rsc, so we don't have to do
that fiddling down the road.
