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

Message-Id: <1e0fc615-101c-7b9d-6dd1-de9a43fae734@linux.ibm.com>
Date:   Wed, 12 Sep 2018 13:42:41 -0400
From:   Tony Krowiak <akrowiak@...ux.ibm.com>
To:     Cornelia Huck <cohuck@...hat.com>,
        David Hildenbrand <david@...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

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.

>