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

From: Halil Pasic
Date: Fri Aug 24 2018 - 06:29:25 EST

On 08/23/2018 07:40 PM, David Hildenbrand wrote:
On 23.08.2018 19:35, Tony Krowiak wrote:
On 08/23/2018 10:59 AM, Pierre Morel wrote:
On 23/08/2018 15:38, David Hildenbrand wrote:
On 23.08.2018 15:22, Halil Pasic wrote:

On 08/23/2018 02:47 PM, Pierre Morel wrote:
On 23/08/2018 13:12, David Hildenbrand wrote:

I'm confused, which 128 bit?

Me too :) , I was assuming this block to be 128bit, but the qci
has 128 bytes....

And looking at arch/s390/include/asm/ap.h, there is a lot of
contained that is definitely not of interest for CPU models...

I wonder if there is somewhere defined which bits are reserved for
future features/facilities, compared to ap masks and such.

This is really hard to understand/plan without access to

You (Halil, Tony, Pier, ...) should have a look if what I described
related to PQAP(QCI) containing features that should get part of
the CPU
model makes sense or not. For now I was thinking that there is
some part
inside of QCI that is strictly reserved for facilities/features
that we
can use.

No there is no such part. The architecture documentation is quite
with some aspects (e.g. persistence) of how exactly some of these
work and are indicated. I'm having a hard time finding my opinion. I
end up asking some questions later, but for now i have to think first.

Just one hint. There is a programming note stating that if bit 2 of the
QCI block is one there is at least one AP card in the machine that
has APXA installed.

I read the architecture so that the APXA has a 'cpu part' (if we are
doing APXA the cpu can't spec exception on certain bits not being zor9)
and a 'card(s) part'.

Since the stuff seems quite difficult to sort out properly, I ask
are there real problems we must solve?

This ultimately seems to be about the migration, right? You say
'This helps
to catch nasty migration bugs (e.g. APXA suddenly disappearing).' at
the very
beginning of the discussion. Yes, we don't have to have an vfio_ap
he guest can and will start looking for AP resources if
only the cpu model features installed. So the guest could observe
a disappearing APXA, but I don't think that would lead to problems
Linux at least).

And there ain't much AP a guest can sanely do without if no AP
are there.

I would really prefer not rushing a solution if we don't have to.

What is apsc, qact, rc8a in the qci blocks? are the facility bits?

Yes, facility bits concerning the AP instructions

According to the current AR document rc8a ain't a facility but bits
0-2 and 4-7 kind of are.

Easy ( :) ) answer. Everything that is the CPU part should get into the
CPU model. Everything that is AP specific not. If APXA is not a CPU
facility, fine with me to leave it out.

Ack to not rushing, but also ack to not leaving out important things.
Ack that this stuff is hard to ficure out.

APXA is not a CPU part, it is a machine part (SIE) and a AP part
it has no influence on CPU instructions but on the AP instructions.
Consequently, if I understood the definition correctly, it should not
go in the CPU model.

The APXA bit returned via the PQAP(QCI) instruction indicates the APXA
facility is
installed in the CPUs of the configuration. This means that the facility is
installed in one or more adjunct processors but not necessarily all.
Given that
it indicates a CPU property, maybe it does belong in the CPU model?

Hmmm, I tend to agree - especially as it affects SIE behavior. But as
this is not a feature block (compared to what I thought), this clould be
model as a CPU feature like AP.

There is certainly a CPU aspect to APXA: before APXA the APQN had to
have zeros in certain bits (otherwise specification exception). When
running with APXA we have a guarantee that there won't be any
specification exception flying because such an bit is set. The interesting
question is, is APXA constant let's say as long as an LPAR partition is