>>> >> 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. -- Thanks, David / dhildenb
