Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xen-shell-cmd: Allow config selection for domain creation #57

Merged
merged 3 commits into from
May 13, 2024

Conversation

Deedone
Copy link
Contributor

@Deedone Deedone commented Apr 1, 2024

Add linker script to collect all domain configs in one place. Add macro DECL_CONFIG to mark domain config structures. Specific config can be selected for domain creation by name via the shell command line parameter.

xen-shell-cmd/src/xen_cmds.c Outdated Show resolved Hide resolved
xen-shell-cmd/src/xen_cmds.c Outdated Show resolved Hide resolved
@@ -15,7 +16,8 @@

LOG_MODULE_REGISTER(xen_shell);

extern struct xen_domain_cfg domd_cfg;
Copy link
Collaborator

@xakep-amatop xakep-amatop Apr 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be nice to put domd_cfg in domain_configs
or mark this struct that it should be placed in the section

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention of this change is to remove the direct dependency on external variable. Section attributes should be added in the same place where the config struct is declared, which is currently in the AOS project.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand. I mean, could you open a pull request with the necessary changes so that we can use the 'xu create' command with domD as well?

@Deedone
Copy link
Contributor Author

Deedone commented Apr 4, 2024

Rebased and implemented suggestions.

@oleksiimoisieiev
Copy link
Contributor

Checkpatch check was failed

@Deedone
Copy link
Contributor Author

Deedone commented Apr 17, 2024

Checkpatch check was failed

It is a false positive.

@GrygiriiS
Copy link

GrygiriiS commented Apr 22, 2024

Why not create _init(struct xen_domain_cfg*) for library? It really should be problem of Zephyr app and not a library where to place/get dom_cfgs.

@Deedone
Copy link
Contributor Author

Deedone commented Apr 24, 2024

Depends on #74

@Deedone
Copy link
Contributor Author

Deedone commented Apr 24, 2024

Why not create _init(struct xen_domain_cfg*) for library? It really should be problem of Zephyr app and not a library where to place/get dom_cfgs.

This will force every application developer to come up with a similar system. I believe it is better to hide the complexity within a library, instead of forcing it onto its users.

@GrygiriiS
Copy link

Why not create _init(struct xen_domain_cfg*) for library? It really should be problem of Zephyr app and not a library where to place/get dom_cfgs.

This will force every application developer to come up with a similar system. I believe it is better to hide the complexity within a library, instead of forcing it onto its users.

It forces applications to use some linker sections which in turn adds:

  • platform specific issues/dependencies like cons & not const, XIP vs not XIP
  • prevents placing/retrieving dom_cfg form anywhere like shared mem, or placing cfg in FIP image for example (FIP can be attached to Zephyr binary and prepared outside of Zephyr build system)
  • prevents form building and using dynamic cfg list (i do not like it but could happen)

Playing with linker in Zephyr is powerful tool from one side, but painful from another - ask @oleksiimoisieiev.

Really, simplest possible solution for library is xenlib_int().

@lorc
Copy link
Collaborator

lorc commented Apr 24, 2024

I agree with @GrygiriiS here. App should provide own callbacks for obtaining configs, images, etc. We can provide some generic implementation in xenlib for a default use case. But it should be strictly optional.

@GrygiriiS
Copy link

I agree with @GrygiriiS here. App should provide own callbacks for obtaining configs, images, etc. We can provide some generic implementation in xenlib for a default use case. But it should be strictly optional.

Hope I understood you idea right, add

typedef int  (*domain_get_cfg_cb_t)(const uint32_t domid,  const struct xen_domain_cfg **dom_cfg);

int domain_set_get_cfg_cb(domain_get_cfg_cb_t cb);

The main user for now is XEN shell. A small question about func naming, but I like the Idea.

@Deedone
Copy link
Contributor Author

Deedone commented Apr 26, 2024

Added additional way for apps to provide their configs
Added config option to disable additional section creation

Waiting for merge of #74 to update cmdline interface

@@ -151,6 +198,9 @@ SHELL_STATIC_SUBCMD_SET_CREATE(
" Unpause Xen domain\n"
" Usage: unpause -d <domid>\n",
domu_unpause, 3, 0),
SHELL_CMD_ARG(config_list, NULL,
" List available domain configurations\n",
xen_config_list, 1, 0),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about "config list"? With possibility to have "config dump" in the future, for example?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion but I am not sure if this change will provide any actual benefit.


for (i = 0; i < domain_get_user_cfg_count(); i++) {
cfg = domain_get_user_cfg(i);
shell_print(shell, "%s", cfg->name);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add index in print, pls? "%d %s" <- i, name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because it will add confusion suggesting to users that they can somehow use this number somewhere.


#ifdef CONFIG_XEN_DOMCFG_SECTION
for (cfg = _domain_configs_start; cfg < _domain_configs_end; cfg++) {
shell_print(shell, "%s", cfg->name);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add index in print, pls? "%d %s" <- i, name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

@GrygiriiS
Copy link

Tested-by: Grygorii Strashko <[email protected]>

_domain_configs_start = .;
KEEP(*(.domain_configs))
_domain_configs_end = .;
} > RAM
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which section it will reside at the end? I expect it to get somewhere in .rodata

Copy link

@GrygiriiS GrygiriiS May 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no :P Not exactly :) Now it can't be made const. More over, it depends on iomems, dtdevs, dt_passthrough.
Now it can be only in RAM

I kinda did experiment to build dom_cfg.c with one config as .o outside Zephyr - results are not encouraging.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a pity. On other hand, I can imagine that someone might want to alter configuration in run-time. So maybe, in the end, this is not as bad as it seems.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, back_cfg is stored in xen_domain_cfg struct, it is filled manually by app or via xrun external configuration before domain is created. Thus we definitely need it to be r/w or rework xrun + app processing to separate structure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is at the end of data_region

@@ -616,6 +617,21 @@ struct xen_domain *domid_to_domain(uint32_t domid)
return NULL;
}

struct xen_domain_cfg *domain_find_config(char *name)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const char *name

@Deedone Deedone force-pushed the multiconfig branch 2 times, most recently from 501b007 to e28b8d2 Compare May 10, 2024 08:41
Copy link
Collaborator

@lorc lorc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

Reviewed-by: Volodymyr Babchuk <[email protected]>

Copy link
Collaborator

@firscity firscity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed-by: Dmytro Firsov <[email protected]>

Add linker script to collect all domain configs in one place.
Add macro DECL_CONFIG to mark domain config structures.
Specific config can be selected for domain creation by name via the
shell command line parameter.

Signed-off-by: Mykyta Poturai <[email protected]>
Tested-by: Grygorii Strashko <[email protected]>
Reviewed-by: Volodymyr Babchuk <[email protected]>
Reviewed-by: Dmytro Firsov <[email protected]>
Deedone added 2 commits May 13, 2024 14:45
Provide weak functions for user configurations in the xen-dom-mgmt
allowing apps to extend the list of configurations for a domain.

Signed-off-by: Mykyta Poturai <[email protected]>
Tested-by: Grygorii Strashko <[email protected]>
Reviewed-by: Volodymyr Babchuk <[email protected]>
Reviewed-by: Dmytro Firsov <[email protected]>
Add a new command to list available domain configurations.

Signed-off-by: Mykyta Poturai <[email protected]>
Tested-by: Grygorii Strashko <[email protected]>
Reviewed-by: Volodymyr Babchuk <[email protected]>
Reviewed-by: Dmytro Firsov <[email protected]>
@firscity firscity merged commit 531d52b into xen-troops:main May 13, 2024
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants