Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains

[Tony Krowiak]

On 08/22/2018 05:42 AM, Cornelia Huck wrote:
> On Wed, 22 Aug 2018 01:18:20 +0200
> Halil Pasic <pasic@xxxxxxxxxxxxx> 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.



>