On 09/24/2018 09:22 AM, Harald Freudenberger wrote:
On 24.09.2018 14:16, Halil Pasic wrote:
On 09/24/2018 01:36 PM, Cornelia Huck wrote:
(...)
...and here, we return the last error of any of the resets. Two
questions:
- Does it make sense to continue if we get -EIO? IOW, does "really
broken" only refer to a certain tuple and other tuples still can/need
to be reset?
I think it does make sense to continue, because IMHO "things are really
broken" is an overstatement (I mean the APQN invalid case). One could
argue would skipping the current card (adapter) be justified or not.
IMHO the current code is good enough for the first shot, and we can think
about fine-tuning it later.
Absolutely. The -EIO case is reached for example when the APQN
is 'deconfigured' which means the crypto adapter is logically unplugged.
So the -EIO case should NOT lead to some fatal actions like panic()
or cause a KVM guest to shut down or so.
- Is the return code useful in any way, as we don't know which tuple it
refers to?
Well, good question. It conveys that the operation can 'fail'. AFAIR -EBUSY
is mostly fine given what the architecture say if we are satisfied with just
reset. And the cases behind -EIO might actually be OK too in the same sense.
My guess is, that based on the return value client code can tell if we have
zeroize for all queues or basically just reset (like rapq). We could log that
to some debug facility or whatever -- I guess, but at the moment we don't care.
In the end I think the code is good enough as is, and if we want we can
improve on it later.
Regards,
Halil
I'll note that in v7 a message was logged to indicate for which APQN the
error occurred, but I was asked to remove the printk log messsages. I
agree with Halil and Harald confirmed that the code is probably okay as
it stands. I can definitely see enhancing all of AP virtualization down
the road with some type of debug logging.
