Messages in this thread | | | Subject | Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains | From | Tony Krowiak <> | Date | Wed, 22 Aug 2018 11:18:52 -0400 |
| |
On 08/22/2018 05:42 AM, Cornelia Huck wrote: > On Wed, 22 Aug 2018 01:18:20 +0200 > Halil Pasic <pasic@linux.ibm.com> wrote: > >> On 08/21/2018 07:07 PM, Tony Krowiak wrote: >>> This convention has been enforced by the kernel since v1. This is also >>> enforced by both the LPAR as well as in z/VM. The following is from the >>> PR/SM Planning Guide: >>> >>> Control Domain >>> A logical partition's control domains are those cryptographic domains for which remote secure >>> administration functions can be established and administered from this logical partition. This >>> logical partition’s control domains must include its usage domains. For each index selected in the >>> usage domain index list, you must select the same index in the control domain index list >>> > That's interesting. > >> IMHO this quote is quite a half-full half-empty cup one: >> * it mandates the set of usage domains is a subset of the set >> of the control domains, but >> * it speaks of independent controls, namely about the 'usage domain index' >> and the 'control domain index list' and makes the enforcement of the rule >> a job of the administrator (instead of codifying it in the controls). > I'm wondering if a configuration with a usage domain that is not also a > control domain is rejected outright? Anybody tried that? :)
That's been tried and is not rejected.
> >>> Consequently, I'm going to opt for ensuring this is clearly documented. Based on the fact you've >>> requested clarification of many points described in this section of the doc, I >>> think I'll try putting my meager skills as a wordsmith to work to hopefully clarify things. >>> I'll run it by you when I complete that task to see if I've succeeded:) >> I don't think just a doc update will do. Let me explain why. >> >> What describe as "... note that the AQM and ADM masks configured for the >> mediated matrix device will be logically OR'd together to create the ADM >> stored in the CRYCB referenced from the guest's SIE state description." >> is a gotcha at best. The member of struct ap_matrix and the member of the >> respective apcb in the crycb are both called 'adm', but ap_matrix.adm is >> not an ADM as we know it from the architecture, but rather ~ AQM & ADM. >> >> I feel pretty strongly about this one. If we want to keep the enforcement >> in the kernel, I guess, the assign_domain should set the bit corresponding >> bit not only in ap_matrix.aqm but also in ap_matrix.adm. When the >> ap_matrix is committed into the crycb no further manipulating the masks >> should take place. > Would you be fine if the control domain interface stated that it is > used to configure _additional_ control domains and the usage domain > interface stated that it is used to define usage and implicitly also > control domains? (And make the usage domain interface also set the > equivalent bit in the control domain mask.)
I think that is the better way to go and is something Halil recommended in another post.
> >> I don't feel strongly about whether to enforce this convention about AQM >> and ADM in the kernel or not. Frankly, I don't know what is behind the >> rule. Since I can't tell if any problems are to be expected if this >> convention is violated, I would feel more comfortable if the rule was >> accommodated higher in the management stack. > I guess it depends: > > - If this is a case of: "Don't configure control domains that are not > also usage domains. You are likely to go through > {code,firmware,hardware} paths that are generally not used.", > configure it in the kernel. > - If this rather is "Everybody is doing that, it's a general > convention.", configure it higher up in the stack (libvirt?)
I have come to the conclusion that the convention should be enforced in the sysfs interfaces of the mediated matrix device as follows:
1. All domains assigned as usage domains will also be implicitly assigned as control domains.
2. Control domains that are not usage domains may be assigned via the assign_control_domain interface.
My reason is to maintain consistency across platforms, because:
1. The architecture doc states that control domains are a superset of the usage domains.
2. The HMC interface for assigning domains to the LPAR enforces the convention.
3. The PR/SM documentation states the same.
>
| |