On 22.08.2018 12:42, Pierre Morel wrote:OK
On 22/08/2018 10:44, David Hildenbrand wrote:host here most probably means "we as a hypervisor that probe for APXA".
On 22.08.2018 10:41, Pierre Morel wrote:The point is that the documentation states that bit 30 is ignored
On 22/08/2018 10:25, David Hildenbrand wrote:As our guest does not see APXA, why should it be allowed to make use of
On 22.08.2018 10:08, Pierre Morel wrote:With APXA.
Currently when shadowing the CRYCB on SIE entrance, the validationI have to trust you on that :)
tests the following:
- accept only FORMAT1 or FORMAT2
- test if MSAext facility (76) is installed
- accept the CRYCB if no keys are used
- verifies that the CRYCB format1 is inside a page
- verifies that the CRYCB origin is not 0
This is not following the architecture.
On SIE entrance, the CRYCB must be validated before acceptingWith which facility was FORMAT2 introduced?
any of its entries.
Let's do the validation in the right order and also verify
correctly the FORMAT2 CRYCB.
KVM initialization setup CRYCB format according to the presence
of APXA for FORMAT2 or FORMAT1
FORMAT2 here already?
In my opinion, the size check you are adding is in the current state not
if the APXA facility is not installed in the **host** configuration.
This is to differentiate it from "APXA installed in the guest
configuration" - e.g. via AP execution control. No AP, no APXA, no
FORMAT 2 accepted. -> Bit ignored.
Don't confuse it with "machine configuration". (mixing that in makes
things way too complicated)
Which I understand as FORMAT2 may not be ignored if APXA is installed"host" is used to differentiate from "guest". If we are at G1 level and
in the host configuration.
there is no APXA, the FORMAT2 bit is to be ignored.
From the host, we control the guest1 and we start it without APNo AP implies no APXA. On that logical level "host".
by not setting ECA.28.
So that the guest1 can not know if APXA is installed or not since to know
this it must use a AP instruction :)
Now the guest1 is an hypervizor and wants to start a guest2.ECA.28 has no effect as G1 sees no AP facility. That is the real reason.
It can set ECA.28 to allow the guest2 AP instructions , just because it can,
(even guest2 will not see any as it will be masked by the guest1 ECA.28
that we did not set)
It can also set the FORMAT2 just because it can do it.Keep it simple. Don't mix in machine configuration. Try to make each
The documentation explicitly says that FORMAT2 may be used
without APXA and that in this case it will be handled as a FORMAT1
The question is do we want to forbid this?
It is not an error.
Suppose that an hypervizor always set FORMAT2 to be able to not restart
its guest if the host set ECA.28 a posteriori.
Anyway we have the choice:
- we verify the CRYCB for FORMAT2
- we forbid FORMAT2
Since we will soon (I hope) be able to use AP instructions in AP
but we are not able to do it today, we could forbid FORMAT2
however in the current behavior we authorize FORMAT2...
What ever the choice is we must change the current implementation.
I prefer to keep the current interface but make sure that the
host do not crash when scheduling a FORMAT2 SIE crossing
a page boundary.
What do you think we should do?
layer look consistent.
If there is no AP/APXA on a level ("host"), FORMAT2 is ignored in SIE.
If there is no AP/APXA on a level ("host"), ECA.28 is ignored in SIE.
If there is no MSA3 on a level ("host"), ECB3_AES | ECB3_DEA is ignored
If there is no AP/APXA/MSA3 on a level ("host"), crycbd is completely
ignored in SIE. (that means, no validity intercepts to be injected).
Please double check that in the documentation.
If there is is AP/MSA3 and either ECA.28 | ECB3_AES | ECB3_DEA, what
should happen? (please verify in the documentation)
FORMAT2 should really only be allowed if there is APXA. As we cannot
fake abscence for guests (as of now), guest availability always matches
host availability if AP is enabled for a guest.