xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Re: [Xen-devel] xen/arm dts: Check "reg" property length in process_multiboot_node
       [not found] ` <5f0f6188-2205-2114-d353-e7eb09d9ba22@arm.com>
@ 2019-06-26 15:56   ` Viktor Mitin
  0 siblings, 0 replies; only message in thread
From: Viktor Mitin @ 2019-06-26 15:56 UTC (permalink / raw)
  To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, Stefano Stabellini

Hi Julien,

Thank you for information provided.
Per the binding, domU1 node should contain the properties
#address-cells and #size-cells.

Adding xen-devel to CC.

Thanks


On Wed, Jun 26, 2019 at 6:42 PM Julien Grall <julien.grall@arm.com> wrote:
>
>
>
> On 26/06/2019 16:21, Viktor Mitin wrote:
> > Hi All,
>
> Hi,
>
> Would you mind to add xen-devel on CC? This discussion could benefits everyone.
>
> > While setting up dom0less configuration as described in
> > docs/features/dom0less.pandoc
> > it has been found out that Xen doesn't check the length of the DT reg property.
>
> What do you mean? The panic below clearly shows Xen is checking the length of
> the DT reg property.
>
> > This seems an old issue described in [1]. However, the tests with
> > dom0less domU1 setup show that the issue is still relevant at least in
> > case of xen 4.12:
> >
> >      domU1 {
> >          compatible = "xen,domain";
> >          memory = <0x20000>;
> >          cpus = 1;
> >          vpl011;
> >
> >          module@2000000 {
> >              compatible = "multiboot,kernel", "multiboot,module";
> >              reg = <0x2000000 0xffffff>;
> >              bootargs = "console=ttyAMA0";
> >          };
> >
> >          module@30000000 {
> >              compatible = "multiboot,ramdisk", "multiboot,module";
> >              reg = <0x3000000 0xffffff>;
> >          };
> >      };
> >
> > The reg property in this example doesn't work - Xen panics with it.
> > It should be described as
> > reg = <0x0 0x2000000 0x0 0xffffff>;
> > or as
> > #address-cells <1>
> > #size-cells <1>
> > reg = <0x2000000 0xffffff>;
> >
> > In other case xen panics on the next code:
> > In xen/arch/arm/bootfdt.c:
> >
> >       if ( len < dt_cells_to_size(address_cells + size_cells) )
> >           panic("fdt: node `%s': `reg` property length is too short\n",
> >                       name);
> >
> > Because in case of arm64 dom0less example reg len calculation looks next:
> > len == 8,
> > dt_cells_to_size(address_cells + size_cells) == 16
> > address_cells == 2
> > size_cells == 2
> >
> > Both solutions mentioned above has been tested and works well.
> > The thing is that dom0less documentation has and example which doesn't
> > work in case of arm64 and it should be improved with this information
> > or it needs to fix "reg" property length calculation.
>
> The example in docs/features/dom0less.pandoc does not match the bindings
> described in docs/misc/arm/device-tree/booting.txt.
>
> Per the binding, domU1 node should contain the properties #address-cells and
> #size-cells.
>
> >
> > What do you think?
>
> The code works as expected, however the documentation needs to be updated.
>
> >
> > <1>  https://lists.xenproject.org/archives/html/xen-devel/2013-09/msg00642.html
> >
> > Thanks,
> > Viktor Mitin
> >
>
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-06-26 15:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAOcoXZZW-aoQUgMJFKJ9hj9bcFjojOST_i+ifmjZDvosGo8LCQ@mail.gmail.com>
     [not found] ` <5f0f6188-2205-2114-d353-e7eb09d9ba22@arm.com>
2019-06-26 15:56   ` [Xen-devel] xen/arm dts: Check "reg" property length in process_multiboot_node Viktor Mitin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).