On 08/22/2017 04:15 PM, Cornelia Huck wrote:
> On Tue, 22 Aug 2017 15:54:32 +0200
> Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
>
>> On 08/22/2017 03:24 PM, Cornelia Huck wrote:
>>> On Tue, 22 Aug 2017 14:58:37 +0200
>>> Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
>
>>>> The availability of SCLP_CMDW_{,DE}CONFIGURE_IOA is indicated
>>>> by the result of the read scp info command read info in
>>>> ReadInfo.facilities. I think we should assume that the read scp
>>>> info command is always there.
>>>
>>> Sure. But see the question in my other mail regarding the sclp
>>> facilities bit (does it cover pci or adapter reconfiguration?)
>>
>> It (SCLP_HAS_PCI_RECONFIG) exactly covers adapter reconfiguration.
>> That's what I tried to say with the paragraph above.
>
> Sorry, I did not get that before. So we have another confusing name...
>
> I'll just provide SCLP_HAS_PCI_RECONFIG unconditionally. Maybe
> s/PCI/IOA/ here as well?
>
Yeah, I had the same idea a coupe of lines below.
>>
>>>
>>>>
>>>> I would appreciate someone with AR access double checking.
>>>
>>> I'd have hoped you had AR access :p
>>
>> Yes, my statements are based solely on my reading of the AR (me
>> still lacks druid-knowledge). What I've asked for is a second
>> opinion (because AR-s are a twisty maze).
>
> Be careful that you don't get eaten by a grue.
>
>>
>>>
>>>>
>>>>>
>>>>> There's still the question of when this sclp command first became
>>>>> available...
>>>>>
>>>>
>>>> I would argue that it should not be important for AR
>>>> compliance. Currently it operates only on PCI so I doubt it
>>>> pre-dates PCI. But I don't think the current implementation
>>>> is buggy because it offers the sclp command regardless
>>>> of the zPCI facility.
>>>
>>> I'm just wondering if there's another facility we're missing. The zpci
>>> facility might imply presence of adapter reconfiguration, but are there
>>> other facilities implying that as well, or even a dedicated facility?
>>
>> Yes. The SCLP facility with the facility code 33 (aka SCLP_HAS_PCI_RECONFIG).
>> It is the dedicated facility.
>
> OK.
>
>>
>> I don't think zPCI architecturally implies the presence of this SCLP
>> command. And logically I would say it's either the other way around
>> adapter reconfiguration implies zPCI (because otherwise adapter
>> reconfiguration would be completely useless) or bidirectional.
>
> Not sure how useful pci would be without this. I'll just assume that we
> have the facility, regardless whether pci is enabled for that
> particular machine or not.
I have no idea if there is another mechanism to put a pci adapter
into a configuration. If there isn't then we can agree on not too
useful.
>
>>
>>>
>>>>
>>>> I don't know where should I look for the historical details
>>>> which go beyond the AR.
>>>
>>> If there is no independent facility, it is probably best to just always
>>> provide the command, but fail for pci adapter type if the zpci facility
>>> is off.
>>
>> IMHO we should SCLP_RC_INVALID_SCLP_COMMAND iff we don't provide
>> SCLP_HAS_PCI_RECONFIG (which has bad name again s/PCI/IOA).
>
> Nod.
>
>>
>> I don't know of any facility except basic SCLP on which
>> SCLP_HAS_PCI_RECONFIG depends on.
>>
>> For me both presenting and not presenting SCLP_HAS_PCI_RECONFIG
>> to the guest (via read SCP info SCLP command) in the absence of
>> the zPCI feature makes sense. The late because of the likely historical
>> reasons, the former because I think the AR allows it and it gives us more
>> flexibility.
>
> I'll go with always presenting it. We'll just fail with invalid adapter
> type for !pci.
>
> Thanks for digging through the AR!
>
You are welcome. I think we are in agreement. Looking forward to v2.
Halil
