On 08/22/2018 05:48 PM, Christian Borntraeger wrote:
On 08/22/2018 05:34 PM, Pierre Morel wrote:
On 22/08/2018 17:11, Christian Borntraeger wrote:
On 08/22/2018 01:03 PM, Pierre Morel wrote:
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? :)
Yes, and no it is not.
We can use a queue (usage domain) to a AP card for SHA-512 or RSA without
having to define the queue as a control domain.
Huh? My HMC allows to add a domain as
- control only domain
- control and usage domain.
But I am not able to configure a usage-only domain for my LPAR. That seems to match
the current code, no?
Yes, it may not be configurable by the HMC but if we start a guest with no control domain it is not a problem to access the hardware through the usage domain.
I tested this a long time ago, but tested again today to be sure on my LPAR.
AFAIU adding a control only domain and a control and usage domain
allows say:
control and usage domain 1
control only domain 2
Allow to send a message to domain 2 using queue 1
Allow also to send a domain modifying message to domain 1 using queue 1
control domain are domain which are controlled
So you have changed the code to not automatically make a usage domain a
control domain in the bitfield (and you could still use it as a usage
domain). Correct?
I tested basically the same yesterday, with the same results.
I think this is probably expected. the "usage implies control" seems to
be a convention implemented by HMC (lpar) and z/VM but millicode offers
the bits to have usage-only domains. As LPAR and z/VM will always enable
any usage-domain to also be a control domain we should do the same.
I'm fine either way, but slightly prefer higher level management software
and not the kernel accommodating this convention.
Please consider a quote from Harald's mail in another sub-thread
"""
... about control domains
Talked with the s390 firmware guys. The convention that the control domain
mask is a superset of the usage domain mask is only true for 1st level guests.
It is absolutely valid to run a kvm guest with restricted control domain
mask bitmap in the CRYCB. It is valid to have an empty control domain mask
and the guest should be able to run crypto CPRBs on the usage domain(s) without
any problems. However, nobody has tried this.
"""
I'm yet to get an explanation why was this convention established in the first
place. And I can not figure it out myself. For me a setup where I know that
the domains used by some guest can not be modified by the same guest makes
perfect sense. If I try to think in analogies, I kind of compare modification
(that is control domain) with write access, and usage (that is usage domain)
with read access to, let's say a regular file. For me, all options (rw, r, and w)
do make sense, and if I had to pick the one that makes the least sense I would
pick write only. The convention is in these terms making read-only illegal. But
should 'usage only domains' ever get identified as something somebody wants to do
we can just add an attribute for that. So I'm fine either way.
Still I find the commit message for this patch, the implementation of
assign_control_domain() and also the documentation slightly misleading regarding
what does one get from assign_domain.
Regards,
Halil
It seems that the HMC enforce the LPARs to have access to their usage domain (AFAIU from Harald)
