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?
Implementing that should be easy - and I don't like gluing features
together in such a way.
You can always assure that consistent data (e.g. AP + APXA availability)
is reported from KVM to QEMU.
Regards,
Pierre
