On 08/23/2018 04:24 AM, Cornelia Huck wrote:
On Thu, 23 Aug 2018 09:48:48 +0200
David Hildenbrand <david@xxxxxxxxxx> 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.
