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

[David Hildenbrand]

On 22.08.2018 23:05, Tony Krowiak wrote:
> On 08/22/2018 12:57 PM, David Hildenbrand wrote:
>>>>> In this case we will have no problem with older guests not having idea
>>>>> about APXA.
>>>>>
>>>>> Would it be a solution?
>>>> Any feature the guest sees, should be part of the CPU model. The whole
>>>> environment for cpu subfunctions is already in place both in KVM and
>>>> QEMU. Only disabling subfunctions in KVM is not implemented yet.
>>>>
>>>> You can exclude any subfunctions/facilities that are only valid on LPAR
>>>> level and cannot be used in some guest either way. (that makes life
>>>> sometimes easier)
>>>>
>>>>
>>>> I know that this might sound a little bit complicated, but it really
>>>> isn't. Boils down to modifying kvm_s390_cpu_feat_init() and specifying
>>>> some features+feature groups in QEMU.
>>> OK, we definitively need another patch/patch-set, to handle this.
>>> Do you think it can be done in another series since if we always support
>>> APXA when we have AP instructions, we already have an indication that
>>> APXA exist: the AP facility.
>>>
>> Please implement the subfunction stuff right away. This will allow to
>> handle all future facilities transparently from a kernel POV.
> 
> I find your use of the term 'subfunction' confusing here. In the
> kvm_s390_cpu_feat_init(void) function, it looks like the
> kvm_s390_available_subfunc structure is filled in with bits
> returned from CPACF queries of various MSA facilities to indicate
> which CPACF functions are supported. APXA is not a subfunction but
> a facility that is indicated by a bit returned from the PQAP(QCI)
> instruction. If we are to implement this, wouldn't it be done as
> a CPU model feature as opposed to a subfunction? Am I
> misunderstanding what you are asking for?

Yes, "subfunction" is a confusing terminology. (I once called it
subfeature/sufacility, but ended up using subfunction).

>From a high level perspective, these are just feature bits - "can I use
feature X" / "is feature X available".

What all of these "query" blocks (MSA, PLO, PQAP(QCI) ...) have in
common is:
- in contrast to STFL(E), they are as a default not modified by the
  hypervisor but silently passed through
- dropping one of the bits (e.g. APXA) can break the guest - guest
  visible ABI
- any newly added feature/facility in such a block (new HW generation)
  should be transparently handled by HW and not require modifications in
  the hypervisor - because they are right away presented to the guest.
  (unfortunately with minor exceptions - e.g. APXA might be such a
  candidate, but that was rather a design error back then)
- there is a way we can overwrite which features are presented to the
  guest

The nice thing about that "blob" exported to user space (in contrast to
features) is that it does not have to be fixed up in KVM every time a
new feature/facility is added. As they should be transparently handled.
Only QEMU has to be thought about the new feature - which can be done
right away when introducing the new CPU model.

That's why the natural choice for PQAP(QCI) is also exposing it as
subfunctions, and not as CPU model features (kvm interface).

-- 

Thanks,

David / dhildenb