This small series is meant as an example how to add further dynamical
directories to hypfs. It can be used to replace Paul's current approach
to specify ABI-features via domain create flags and replace those by
hypfs nodes.

The related libxl part could just use libxenhypfs to set the values.

This series is meant to be applied on top of my series:

  xen: support per-cpupool scheduling granularity

Juergen Gross (3):
  xen/hypfs: add support for bool leafs in dynamic directories
  xen/domain: add domain hypfs directories
  xen/domain: add per-domain hypfs directory abi-features

 docs/misc/hypfs-paths.pandoc |  10 ++
 xen/common/Makefile          |   1 +
 xen/common/hypfs.c           |  53 +++++++++--
 xen/common/hypfs_dom.c       | 176 +++++++++++++++++++++++++++++++++++
 xen/include/xen/hypfs.h      |   7 ++
 xen/include/xen/sched.h      |   4 +
 6 files changed, 244 insertions(+), 7 deletions(-)
 create mode 100644 xen/common/hypfs_dom.c

-- 
2.26.2

Hi,

On 09/12/2020 16:16, Juergen Gross wrote:
> This small series is meant as an example how to add further dynamical
> directories to hypfs. It can be used to replace Paul's current approach
> to specify ABI-features via domain create flags and replace those by
> hypfs nodes.

This can only work if all the ABI-features are not required at the time 
of creating the domain.

Those features should also be set only once. Furthermore, HYPFS is so 
far meant to be optional.

So it feels to me Paul's approach is leaner and better for the 
ABI-features purpose.

Cheers,

-- 
Julien Grall

On 09.12.20 17:24, Julien Grall wrote:
> Hi,
> 
> On 09/12/2020 16:16, Juergen Gross wrote:
>> This small series is meant as an example how to add further dynamical
>> directories to hypfs. It can be used to replace Paul's current approach
>> to specify ABI-features via domain create flags and replace those by
>> hypfs nodes.
> 
> This can only work if all the ABI-features are not required at the time 
> of creating the domain.

Yes. In case there is some further initialization needed this has to be
done later depending on the setting.

> Those features should also be set only once. Furthermore, HYPFS is so 
> far meant to be optional.

"set once" isn't the point. They should not be able to change after the
domain has been started, and that is covered.

> 
> So it feels to me Paul's approach is leaner and better for the 
> ABI-features purpose.

Depends.

My approach doesn't need any tools side changes after first
implementation when adding new abi-features. And it isn't expanding an
unstable interface.

In the end this is the reason I marked this series as RFC. If using
flags is preferred, fine.


Juergen

On 10/12/2020 07:49, Jürgen Groß wrote:
> On 09.12.20 17:24, Julien Grall wrote:
>> Hi,
>>
>> On 09/12/2020 16:16, Juergen Gross wrote:
>>> This small series is meant as an example how to add further dynamical
>>> directories to hypfs. It can be used to replace Paul's current approach
>>> to specify ABI-features via domain create flags and replace those by
>>> hypfs nodes.
>>
>> This can only work if all the ABI-features are not required at the 
>> time of creating the domain.
> 
> Yes. In case there is some further initialization needed this has to be
> done later depending on the setting.
We used to allocate vCPUs after the domain has been created. But this 
ended up in a can of worms because this requires a careful ordering of 
the hypercalls.

So I would rather like to avoid introducing similar operation again...

> 
>> Those features should also be set only once. Furthermore, HYPFS is so 
>> far meant to be optional.
> 
> "set once" isn't the point. They should not be able to change after the
> domain has been started, and that is covered.

That really depends on the flag. Imagine there are dependencies between 
flags or memory needs to be allocated.

> 
>>
>> So it feels to me Paul's approach is leaner and better for the 
>> ABI-features purpose.
> 
> Depends.
> 
> My approach doesn't need any tools side changes after first
> implementation when adding new abi-features. And it isn't expanding an
> unstable interface.
> 
> In the end this is the reason I marked this series as RFC. If using
> flags is preferred, fine.

I prefer the flag version. Let see what other thinks.

Cheers,

---
Julien Grall

On 09.12.2020 17:16, Juergen Gross wrote:
> This small series is meant as an example how to add further dynamical
> directories to hypfs. It can be used to replace Paul's current approach
> to specify ABI-features via domain create flags and replace those by
> hypfs nodes.

Actually, before I look at further of the patches here: I seem
to vaguely recall agreement was reached to stick to Paul's
approach for the time being? Or am I misremembering?

Jan

On 08.01.21 16:44, Jan Beulich wrote:
> On 09.12.2020 17:16, Juergen Gross wrote:
>> This small series is meant as an example how to add further dynamical
>> directories to hypfs. It can be used to replace Paul's current approach
>> to specify ABI-features via domain create flags and replace those by
>> hypfs nodes.
> 
> Actually, before I look at further of the patches here: I seem
> to vaguely recall agreement was reached to stick to Paul's
> approach for the time being? Or am I misremembering?

This is my understanding, too.


Juergen