Messages in this thread | | | Subject | Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains | From | Pierre Morel <> | Date | Thu, 23 Aug 2018 12:41:11 +0200 |
| |
On 23/08/2018 11:26, Halil Pasic wrote: > > > On 08/22/2018 09:16 PM, Tony Krowiak wrote: >> On 08/22/2018 01:11 PM, Halil Pasic wrote: >>> >>> >>> 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. >>>>>>>> ... >>>> >>>> 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?
Yes.
>>> >>> 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 think it is the reasonable thing to do.
>>> >>> I'm fine either way, but slightly prefer higher level management >>> software >>> and not the kernel accommodating this convention.
Please, we do not need this in a first version just make it easy stick with what HMC does.
>>> 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.
We do not need to introduce new features now.
regards, Pierre
-- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany
| |