linux-kernel - Re: [PATCH v9 21/22] KVM: s390: CPU model support for AP virtualization

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] [day] [month] [year] [list]

Date:   Mon, 17 Sep 2018 09:57:06 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>,
        Cornelia Huck <cohuck@...hat.com>
Cc:     Tony Krowiak <akrowiak@...ux.vnet.ibm.com>,
        linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, freude@...ibm.com, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, borntraeger@...ibm.com,
        kwankhede@...dia.com, bjsdjshi@...ux.vnet.ibm.com,
        pbonzini@...hat.com, alex.williamson@...hat.com,
        pmorel@...ux.vnet.ibm.com, alifm@...ux.vnet.ibm.com,
        mjrosato@...ux.vnet.ibm.com, jjherne@...ux.vnet.ibm.com,
        thuth@...hat.com, pasic@...ux.vnet.ibm.com, berrange@...hat.com,
        fiuczy@...ux.vnet.ibm.com, buendgen@...ibm.com,
        frankja@...ux.ibm.com
Subject: Re: [PATCH v9 21/22] KVM: s390: CPU model support for AP
 virtualization

Am 12.09.18 um 19:42 schrieb Tony Krowiak:
> On 08/23/2018 04:24 AM, Cornelia Huck wrote:
>> On Thu, 23 Aug 2018 09:48:48 +0200
>> David Hildenbrand <david@...hat.com> wrote:
>>
>>>> Migration of AP devices is not supported by this patch series, so this
>>>> should
>>>> not be an issue.
>>> Might not be a problem now, but could be later. As I said in a different
>>> reply, the CPU model in QEMU does not care about KVM.
>>>
>>> I want the QEMU CPU model and the KVM interfaces to be clean and future
>>> proof. That's why my opinion is to handle PQAP(QCI) just like all the
>>> other "feature blocks" we already have.
>> +1 to that sentiment.
>>
>> It's better to try to get this correct now than having to hack around
>> should we want to implement things in the future.
> 
> Just so we're on the same page here as far as what to expect for v10 of
> this patch series, let me summarize the the very long series of private
> exchanges as well as this thread:
> 
> * The APXA facility indicated by a bit returned in the response to the
>    PQAP(QCI) function indicates only whether the APXA facility is available
>    on one or more APs installed on the system.
> * The only way to change the bit returned from PQAP(QCI) is to intercept the
>    instruction and emulate it, so it makes no sense for passthrough devices.
> * The AP(s) with APXA installed may not necessarily even be in the 
> configuration.
> * The only way to determine whether APXA is installed in a given AP is to
>    query it using the PQAP(TAPQ) instruction.
> 
> It was decided that APXA is better modeled as device configuration. If 
> and when
> emulation is implemented, APXA can be configured for any AP devices assigned
> to a guest. Since AP instructions will be intercepted when emulating AP,
> the PQAP(QCI) instruction can return the APXA bit according to whether any
> AP is configured with APXA installed. That matches the real architecture 
> much
> more closely. So, the bottom line is that we will not introduce a new 
> CPU model
> feature for APXA in v10 of this series.

Yes, that sounds sane to me. In addition, all other QCI indicated
"features/facilitites" are handled on a per-device basis and not on a
CPU-model basis.


-- 

Thanks,

David / dhildenb