From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Volodymyr_Babchuk@epam.com, Achin.Gupta@arm.com,
andrii_anisov@epam.com, Stefano Stabellini <stefanos@xilinx.com>,
xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8 5/8] xen/arm: assign devices to boot domains
Date: Thu, 3 Oct 2019 10:34:56 +0100 [thread overview]
Message-ID: <fce98dfd-9a8b-e615-3799-ff368d4c6527@arm.com> (raw)
In-Reply-To: <20191003013526.30768-5-sstabellini@kernel.org>
Hi Stefano,
A couple of comments below, mostly because I wasn't clear enough on the previous
version. I am not sure if it is worth resending the series, maybe just resending
this one would be sufficient?
On 03/10/2019 02:35, Stefano Stabellini wrote:
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 84b65b8f25..b90902ad97 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1714,6 +1714,88 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
> }
> #endif
>
> +/*
> + * Scan device tree properties for passthrough specific information.
> + * Returns < 0 on error
> + * 0 on success
> + */
> +static int __init handle_passthrough_prop(struct kernel_info *kinfo,
> + const struct fdt_property *xen_reg,
> + const struct fdt_property *xen_path,
> + bool xen_force,
> + uint32_t address_cells, uint32_t size_cells)
> +{
> + const __be32 *cell;
> + unsigned int i, len;
> + struct dt_device_node *node;
> + int res;
> + paddr_t mstart, size, gstart;
> +
> + /* xen,reg specifies where to map the MMIO region */
> + cell = (const __be32 *)xen_reg->data;
> + len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> + sizeof(uint32_t));
Apologies for this, I misread you previous code. I am happy with this version or
the previous one.
[...]
> + /*
> + * Only handle passthrough properties if both xen,reg and xen,path
> + * are present, or if xen,force-assign-without-iommu is specified.
> + */
> + if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
> + {
> + res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
> + address_cells, size_cells);
> + if ( res < 0 )
> + {
> + printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
This is not the error path I meant.
The one I was referring is the case where xen,path is present but not xen,reg.
At the moment you will continue without telling the user. We should at least
print a warning and probably return an error as someone specifying "xen,path"
may expect to assign the device.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-10-03 9:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 1:35 [Xen-devel] [PATCH v8 0/8] dom0less device assignment Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 1/8] xen/arm: introduce handle_device_interrupts Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 2/8] xen/arm: export device_tree_get_reg and device_tree_get_u32 Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 3/8] xen/arm: introduce kinfo->phandle_gic Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 4/8] xen/arm: copy dtb fragment to guest dtb Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 5/8] xen/arm: assign devices to boot domains Stefano Stabellini
2019-10-03 9:34 ` Julien Grall [this message]
2019-10-03 17:30 ` Stefano Stabellini
2019-10-03 9:51 ` Julien Grall
2019-10-03 17:32 ` Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 6/8] xen/arm: handle "multiboot, device-tree" compatible nodes Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 7/8] xen/arm: introduce nr_spis Stefano Stabellini
2019-10-03 1:35 ` [Xen-devel] [PATCH v8 8/8] xen/arm: add dom0-less device assignment info to docs Stefano Stabellini
2019-10-03 9:36 ` Julien Grall
2019-10-03 9:58 ` Julien Grall
2019-10-03 17:36 ` Stefano Stabellini
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=fce98dfd-9a8b-e615-3799-ff368d4c6527@arm.com \
--to=julien.grall@arm.com \
--cc=Achin.Gupta@arm.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrii_anisov@epam.com \
--cc=sstabellini@kernel.org \
--cc=stefanos@xilinx.com \
--cc=xen-devel@lists.xen.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.