Messages in this thread | | | Subject | Re: [PATCH v10 13/26] s390: vfio-ap: zeroize the AP queues | From | Tony Krowiak <> | Date | Mon, 24 Sep 2018 12:42:38 -0400 |
| |
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.
>
| |