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

[David Hildenbrand <david@redhat.com>]

>>>
>> 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