Re: [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

Farhan Ali
2018-12-05T18:34:11Z

On 12/05/2018 07:54 AM, Cornelia Huck wrote:
>> Yeah, that is perfectly clear, but it ain't the complete story. E.g.
>> are subsequent commands blocking until the preceding command finishes
>> is part of the interface. And what is good implementation depends on the
>> answer. What I mean, I first need to understand how things are supposed
>> to work (together) so I can double check that against the
>> implementation. Otherwise all I can do is nitpicking.
>>
>> To get more tangible: we are in the middle of processing an SSCH request
>> (e.g. doing the translation) when a HSCH comes in. What should happen?
>> Should we start processing HSCH after he instruction part of SSCH is
>> done -- which currently includes translation? Or should we -EBUSY? Or do
>> we abort START related activities and do the HALT stuff?
> I think most of the sorting-out-the-operations stuff should be done by
> the hardware itself, and we should not really try to enforce anything
> special in our vfio code.
>
> For your example, it might be best if a hsch is always accepted and
> send on towards the hardware. Probably best to reflect back -EAGAIN if
> we're currently processing another instruction from another vcpu, so
> that the user space caller can retry. Same for ssch, if another ssch is
> already being processed. We*could* reflect cc 2 if the fctl bit is
> already set, but that won't do for csch, so it is probably best to have
> the hardware figure that out in any case.
>
> If I read the code correctly, we currently reflect -EBUSY and not
> -EAGAIN if we get a ssch request while already processing another one.
> QEMU hands that back to the guest as a cc 2, which is not 100% correct.
> In practice, we don't see this with Linux guests due to locking.
>

If we have a ssch and a csch immediately afterwards from userspace, will
we end up issuing csch first and then ssch to the hardware?

If I understand correctly, the ccw translation as part of the ssch can
be a slow operation so it might be possible we issue the csch first?
In that case we won't actually clear the original start function as
intended.

Thanks
Farhan