All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
To: Julien Grall <julien@xen.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Juergen Gross <jgross@suse.com>
Subject: Re: [RFC v2 3/8] xen/arm: Export host device-tree to hypfs
Date: Wed, 9 Feb 2022 10:20:38 +0000	[thread overview]
Message-ID: <20220209102037.GA1025795@EPUAKYIW015D> (raw)
In-Reply-To: <b88f6a50-6e9e-5679-8d25-89e26031e88e@xen.org>

Hi Julien,

On Tue, Feb 08, 2022 at 06:26:54PM +0000, Julien Grall wrote:
> Hi Oleksii,
> 
> On 08/02/2022 18:00, Oleksii Moisieiev wrote:
> > If enabled, host device-tree will be exported to hypfs and can be
> > accessed through /devicetree path.
> > Exported device-tree has the same format, as the device-tree
> > exported to the sysfs by the Linux kernel.
> > This is useful when XEN toolstack needs an access to the host device-tree.
> > 
> > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > ---
> >   xen/arch/arm/Kconfig           |   8 +
> >   xen/arch/arm/Makefile          |   1 +
> >   xen/arch/arm/host_dtb_export.c | 307 +++++++++++++++++++++++++++++++++
> 
> There is nothing specific in this file. So can this be moved in common/?

You're right. I will move it to common.

> 
> >   3 files changed, 316 insertions(+)
> >   create mode 100644 xen/arch/arm/host_dtb_export.c
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index ecfa6822e4..895016b21e 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -33,6 +33,14 @@ config ACPI
> >   	  Advanced Configuration and Power Interface (ACPI) support for Xen is
> >   	  an alternative to device tree on ARM64.
> > +config HOST_DTB_EXPORT
> > +	bool "Export host device tree to hypfs if enabled"
> > +	depends on ARM && HYPFS && !ACPI
> 
> A Xen built with ACPI enabled will still be able to boot on a host using
> Device-Tree. So I don't think should depend on ACPI.
> 
> Also, I think this should depend on HAS_DEVICE_TREE rather than ARM.

I agree. Thank you.

> 
> > +	---help---
> > +
> > +	  Export host device-tree to hypfs so toolstack can have an access for the
> > +	  host device tree from Dom0. If you unsure say N.
> > +
> >   config GICV3
> >   	bool "GICv3 driver"
> >   	depends on ARM_64 && !NEW_VGIC
> > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> > index 07f634508e..0a41f68f8c 100644
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -8,6 +8,7 @@ obj-y += platforms/
> >   endif
> >   obj-$(CONFIG_TEE) += tee/
> >   obj-$(CONFIG_HAS_VPCI) += vpci.o
> > +obj-$(CONFIG_HOST_DTB_EXPORT) += host_dtb_export.o
> >   obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
> >   obj-y += bootfdt.init.o
> > diff --git a/xen/arch/arm/host_dtb_export.c b/xen/arch/arm/host_dtb_export.c
> > new file mode 100644
> > index 0000000000..794395683c
> > --- /dev/null
> > +++ b/xen/arch/arm/host_dtb_export.c
> 
> This is mostly hypfs related. So CCing Juergen for his input on the code.

Thank you.

> 
> > @@ -0,0 +1,307 @@
> > +/*
> > + * xen/arch/arm/host_dtb_export.c
> > + *
> > + * Export host device-tree to the hypfs so toolstack can access
> > + * host device-tree from Dom0
> > + *
> > + * Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > + * Copyright (C) 2021, EPAM Systems.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <xen/device_tree.h>
> > +#include <xen/err.h>
> > +#include <xen/guest_access.h>
> > +#include <xen/hypfs.h>
> > +#include <xen/init.h>
> > +
> > +#define HOST_DT_DIR "devicetree"
> > +
> > +static int host_dt_dir_read(const struct hypfs_entry *entry,
> > +                            XEN_GUEST_HANDLE_PARAM(void) uaddr);
> > +static unsigned int host_dt_dir_getsize(const struct hypfs_entry *entry);
> > +
> > +static const struct hypfs_entry *host_dt_dir_enter(
> > +    const struct hypfs_entry *entry);
> > +static void host_dt_dir_exit(const struct hypfs_entry *entry);
> > +
> > +static struct hypfs_entry *host_dt_dir_findentry(
> > +    const struct hypfs_entry_dir *dir, const char *name, unsigned int name_len);
> 
> This is new code. So can you please make sure to avoid forward declaration
> by re-ordering the code.
> 

I can't avoid forward declaration here because all those functions
should be passed as callbacks for node template dt_dir. And dt_dir is
used in read and findentry functions.

> 
> [...]
> 
> > +static char *get_root_from_path(const char *path, char *name)
> > +{
> > +    const char *nm = strchr(path, '/');
> > +    if ( !nm )
> > +        nm = path + strlen(path);
> > +    else
> > +    {
> > +        if ( !*nm )
> > +            nm--;
> > +    }
> > +
> > +    return memcpy(name, path, nm - path);
> 
> What does guaranteee that name will be big enough for the new value?

I will refactor that.

> 
> > +}
> > +
> > +static int host_dt_dir_read(const struct hypfs_entry *entry,
> > +                            XEN_GUEST_HANDLE_PARAM(void) uaddr)
> > +{
> > +    int ret = 0;
> > +    struct dt_device_node *node;
> > +    struct dt_device_node *child;
> 
> The hypfs should not modify the device-tree. So can this be const?

That's a good point.
Unfortunatelly child can't be const because it is going to be passed to
data->data pointer, but node can be const I think. In any case I will go
through the file and see where const for the device_node can be set.

> 
> > +    const struct dt_property *prop;
> > +    struct hypfs_dyndir_id *data;
> > +
> > +    data = hypfs_get_dyndata();
> > +    if ( !data )
> > +        return -EINVAL;
> 
> [...]
> 
> > +static struct hypfs_entry *host_dt_dir_findentry(
> > +    const struct hypfs_entry_dir *dir, const char *name, unsigned int name_len)
> > +{
> > +    struct dt_device_node *node;
> > +    char root_name[HYPFS_DYNDIR_ID_NAMELEN];
> > +    struct dt_device_node *child;
> > +    struct hypfs_dyndir_id *data;
> > +    struct dt_property *prop;
> > +
> > +    data = hypfs_get_dyndata();
> > +    if ( !data )
> > +        return ERR_PTR(-EINVAL);
> > +
> > +    node = data->data;
> > +    if ( !node )
> > +        return ERR_PTR(-EINVAL);
> > +
> > +    memset(root_name, 0, sizeof(root_name));
> > +    get_root_from_path(name, root_name);
> > +
> > +    for ( child = node->child; child != NULL; child = child->sibling )
> > +    {
> > +        if ( strcmp(get_name_from_path(child->full_name), root_name) == 0 )
> > +            return hypfs_gen_dyndir_entry(&dt_dir.e,
> > +                                  get_name_from_path(child->full_name), child);
> > +    }
> > +
> > +    dt_for_each_property_node( node, prop )
> > +    {
> > +
> > +        if ( dt_property_name_is_equal(prop, root_name) )
> > +            return hypfs_gen_dyndir_entry(&dt_prop.e, prop->name, prop);
> > +    }
> > +
> > +    return ERR_PTR(-ENOENT);
> 
> [...]
> 
> > +static HYPFS_DIR_INIT_FUNC(host_dt_dir, HOST_DT_DIR, &host_dt_dir_funcs);
> > +
> > +static int __init host_dtb_export_init(void)
> > +{
> > +    ASSERT(dt_host && (dt_host->sibling == NULL));
> 
> dt_host can be NULL when booting on ACPI platform. So I think this wants to
> be turned to a normal check and return directly.
> 

I will replace if with
if ( !acpi_disabled )
    return -ENODEV;

> Also could you explain why you need to check dt_host->sibling?
> 

This is my way to check if dt_host points to the top of the device-tree.
In any case I will replace it with !acpi_disabled as I mentioned
earlier.

Best regards,
Oleksii

  reply	other threads:[~2022-02-09 10:21 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 18:00 [RFC v2 0/8] Introduce SCI-mediator feature Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 1/8] xen/hypfs: support fo nested dynamic hypfs nodes Oleksii Moisieiev
2022-02-10  7:34   ` Juergen Gross
2022-02-11  8:16     ` Oleksii Moisieiev
2022-02-11 13:28       ` Juergen Gross
2022-02-11 13:32         ` Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 2/8] libs: libxenhypfs - handle blob properties Oleksii Moisieiev
2022-02-09 13:47   ` Oleksandr Andrushchenko
2022-02-09 14:01     ` Jan Beulich
2022-02-09 14:04       ` Oleksandr Andrushchenko
2022-02-09 14:04   ` Juergen Gross
2022-02-08 18:00 ` [RFC v2 3/8] xen/arm: Export host device-tree to hypfs Oleksii Moisieiev
2022-02-08 18:26   ` Julien Grall
2022-02-09 10:20     ` Oleksii Moisieiev [this message]
2022-02-09 12:17       ` Julien Grall
2022-02-09 14:17         ` Oleksii Moisieiev
2022-02-09 18:51         ` Oleksii Moisieiev
2022-02-09 19:34           ` Julien Grall
2022-02-10  9:38             ` Oleksii Moisieiev
2022-02-09 14:03     ` Juergen Gross
2022-02-08 18:00 ` [RFC v2 4/8] xen/arm: add generic SCI mediator framework Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver Oleksii Moisieiev
2022-02-09 15:02   ` Oleksandr Andrushchenko
2022-02-09 15:23     ` Julien Grall
2022-02-11  8:46   ` Bertrand Marquis
2022-02-11 10:44     ` Oleksii Moisieiev
2022-02-11 11:18       ` Bertrand Marquis
2022-02-11 11:55         ` Oleksii Moisieiev
2022-02-11 23:35           ` Stefano Stabellini
2022-02-12 12:43         ` Julien Grall
2022-02-14 11:13           ` Oleksii Moisieiev
2022-02-14 11:27             ` Bertrand Marquis
2022-02-14 11:51               ` Oleksii Moisieiev
2022-02-14 22:05                 ` Stefano Stabellini
2022-02-16 17:41                   ` Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 6/8] tools/arm: Introduce force_assign_without_iommu option to xl.cfg Oleksii Moisieiev
2022-02-17 14:52   ` Anthony PERARD
2022-02-18  8:19     ` Oleksii Moisieiev
2022-02-17 15:20   ` Julien Grall
2022-02-18  9:16     ` Oleksii Moisieiev
2022-02-18 10:17       ` Julien Grall
2022-02-21 18:39         ` Oleksii Moisieiev
2022-06-03 13:43   ` Jan Beulich
2022-02-08 18:00 ` [RFC v2 7/8] tools/arm: add "arm_sci" " Oleksii Moisieiev
2022-02-08 18:00 ` [RFC v2 8/8] xen/arm: add SCI mediator support for DomUs Oleksii Moisieiev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220209102037.GA1025795@EPUAKYIW015D \
    --to=oleksii_moisieiev@epam.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.