Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 08/22/2017 04:15 PM, Cornelia Huck wrote:
> On Tue, 22 Aug 2017 15:54:32 +0200
> Halil Pasic <pasic@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 <pasic@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