linux-kernel - Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3ca67c61-99a1-c47f-2f79-4ca29cc0f4a4@linux.vnet.ibm.com>
Date:   Tue, 5 Dec 2017 15:47:24 +0100
From:   Pierre Morel <pmorel@...ux.vnet.ibm.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     Harald Freudenberger <freude@...ux.vnet.ibm.com>,
        Tony Krowiak <akrowiak@...ux.vnet.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>, freude@...ibm.com,
        mjrosato@...ux.vnet.ibm.com, pasic@...ux.vnet.ibm.com,
        Boris Fiuczynski <fiuczy@...ux.vnet.ibm.com>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, heiko.carstens@...ibm.com,
        kwankhede@...dia.com, bjsdjshi@...ux.vnet.ibm.com,
        pbonzini@...hat.com, alex.williamson@...hat.com,
        alifm@...ux.vnet.ibm.com, qemu-s390x@...gnu.org,
        jjherne@...ux.vnet.ibm.com, thuth@...hat.com
Subject: Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

On 05/12/2017 15:30, Cornelia Huck wrote:
> On Tue, 5 Dec 2017 15:23:50 +0100
> Pierre Morel <pmorel@...ux.vnet.ibm.com> wrote:
> 
>> On 05/12/2017 15:04, Cornelia Huck wrote:
>>> On Tue, 5 Dec 2017 08:52:57 +0100
>>> Harald Freudenberger <freude@...ux.vnet.ibm.com> wrote:
>>>    
>>>> On 12/02/2017 02:30 AM, Tony Krowiak wrote:
>>>    
>>>>> I agree with your suggestion that defining a new CPU model feature is probably
>>>>> the best way to resolve this issue. The question is, should we define a single
>>>>> feature indicating whether AP instructions are installed and set features bits
>>>>> for the guest based on whether or not they are set in the linux host, or should
>>>>> we define additional CPU model features for turning features bits on and off?
>>>>> I guess it boils down to what behavior is expected for the AP bus running on
>>>>> the linux guest. Here is a rundown of the facilities bits associated with AP
>>>>> and how they affect the behavior of the AP bus:
>>>>>
>>>>> * STFLE.12 indicates whether the AP query function is available. If this bit
>>>>>     is not set, then the AP bus scan will only test domains 0-15. For example,
>>>>>     if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP
>>>>>     queues 04.0047, 05.0047 and 06.0047 will not be made available.
>>>> STFLE 12 is the indication for Query AP Configuration Information (QCI) available.
>>>>> * STFLE.15 indicates whether the AP facilities test function is available. If
>>>>>     this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered
>>>>>     by the AP bus scan will not get bound to any AP device drivers. Since the
>>>>>     AP matrix model supports only CEX4 and greater, no devices will be bound
>>>>>     to any driver for a guest.
>>>> This T-Bit extension to the TAPQ subfunction is a must have. When kvm only
>>>> supports CEX4 and upper then this bit could also act as the indicator for
>>>> AP instructions available. Of course if you want to implement pure virtual
>>>> full simulated AP without any real AP hardware on the host this bit can't
>>>> be the indicator.
>>>
>>> It would probably make sense to group these two together. Or is there
>>> any advantage in supporting only a part of it?
>>>    
>>>>> * STFLE.65 indicates whether AP interrupts are available. If this bit is not
>>>>>     set, then the AP bus will use polling instead of using interrupt handlers
>>>>>     to process AP events.
>>>
>>> So, does this indicate "adapter interrupts for AP" only? If so, we
>>> should keep this separate and only enable it when we have the gisa etc.
>>> ready.
>>>    
>>
>> Yes, STFLE 65, it is for AP only.
>>
>> QCI, STFLE 12, is no present on older systems, in this case AP uses TAPQ
>> to retrieve information for each AP
> 
> Dumb question: How old? Machines that are still supported?

No idea which machine are supported or not, will ask.

What I can say is that I have here a Lpar which does not support QCI.
It seems to be a zEC12.2.
z13 support it.

> 
>>
>> So for my point of view, it make sense to separate the three facilities
>> to enable migration on older systems.
> 
> OK, if STFLE 12 might not be present (pending my question above), but
> STFLE 15 is indeed a must-have, we should split this up.
> 



-- 
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany