On 23/08/2018 09:48, David Hildenbrand wrote:
I really wonder if we should also export the APXA facility.
Given this comment is made within the context of the
FACILITIES_KVM_CPUMODEL I might point out that APXA is not
indicated by a facilities bit. It is indicated by a bit in
the QCI control block returned from the PQAP(QCI)
instruction to indicate that APXA is installed on all CPUs.
We can probe and allow that CPU feature. However, we cannot disable it
(as of now).
Given this patch series implements passthrough devices,
the output of the PQAP(QCI) will always be from a real
device - i.e., there will be no way to disable it.
see below
We have other CPU features where it is the same case (basically all
subfunctions). See kvm_s390_get_processor_subfunc(). We probe them and
export them, but support to disable them has never been implemented.
On a high level, we could then e.g. deny to start a QEMU guest if APXA
is available but has been disabled. (until we know that disabling it
actually works - if ever).
This helps to catch nasty migration bugs (e.g. APXA suddenly
disappearing). Although unlikely, definitely possible.
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.
Don't you mix with the TAPQ instruction which has
a T bit to specify interception.
It indeed is not in the subfunction list even it
has a T bit to indicate interception.
TAPQ-t is indicated through the APFT facility.
We can use this bit as an indication of the presence
of APXA, the documentation mention that both are implemented together.
regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
