[Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Will Abele posted 1 patch 19 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/xen tags/patchew/cover.1562435004.git.will.abele@starlab.io
xen/arch/arm/domain_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

[Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Will Abele 19 weeks ago
From: Will Abele <will.abele@starlab.io>

Hi,

I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux Kernel. I had
trouble getting the 4.14 Linux Kernel to boot as a dom0less domU because it was
misinterpreting the device tree version. Linux 4.14 and earlier interpret device
trees with a "/" in the root node as version 16. Xen produces a version 17
device tree, so the root node needs to be "" to work with 4.14 and earlier Linux
Kernels. Linux 4.15 and later assume that the version is 17, so this patch does
not have any impact.

Please let me know if you need any more information or have suggestions for
other ways to handle this.

Thanks,
Will

Will Abele (1):
  xen/arm: Use "" instead of "/" for domU root node.

 xen/arch/arm/domain_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.20.1 (Apple Git-117)


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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Julien Grall 19 weeks ago

On 06/07/2019 19:02, Will Abele wrote:
> From: Will Abele <will.abele@starlab.io>
> 
> Hi,

Hi,

> I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux Kernel. I had
> trouble getting the 4.14 Linux Kernel to boot as a dom0less domU because it was
> misinterpreting the device tree version. Linux 4.14 and earlier interpret device
> trees with a "/" in the root node as version 16. Xen produces a version 17
> device tree, so the root node needs to be "" to work with 4.14 and earlier Linux
> Kernels. Linux 4.15 and later assume that the version is 17, so this patch does
> not have any impact.
> 
> Please let me know if you need any more information or have suggestions for
> other ways to handle this.

I don't understand where the version comes from. I also don't understand 
how you inferred that Xen is creating a version 17 device-tree.

Do you have link to the paragraph in the specifications?

Cheers,

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Julien Grall 19 weeks ago

On 06/07/2019 19:17, Julien Grall wrote:
> 
> 
> On 06/07/2019 19:02, Will Abele wrote:
>> From: Will Abele <will.abele@starlab.io>
>>
>> Hi,
> 
> Hi,
> 
>> I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux 
>> Kernel. I had
>> trouble getting the 4.14 Linux Kernel to boot as a dom0less domU 
>> because it was
>> misinterpreting the device tree version. Linux 4.14 and earlier 
>> interpret device
>> trees with a "/" in the root node as version 16. Xen produces a 
>> version 17
>> device tree, so the root node needs to be "" to work with 4.14 and 
>> earlier Linux
>> Kernels. Linux 4.15 and later assume that the version is 17, so this 
>> patch does
>> not have any impact.
>>
>> Please let me know if you need any more information or have 
>> suggestions for
>> other ways to handle this.
> 
> I don't understand where the version comes from. I also don't understand 
> how you inferred that Xen is creating a version 17 device-tree.
> 
> Do you have link to the paragraph in the specifications?

Also, please expand what is the exact error. So we can understand 
whether this is the right fix.

Cheers,

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Will Abele 19 weeks ago
The 07/06/2019 18:19, Julien Grall wrote:
> 
> 
> On 06/07/2019 19:17, Julien Grall wrote:
> > 
> > 
> > On 06/07/2019 19:02, Will Abele wrote:
> >> From: Will Abele <will.abele@starlab.io>
> >>
> >> Hi,
> > 
> > Hi,
> > 
> >> I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux 
> >> Kernel. I had
> >> trouble getting the 4.14 Linux Kernel to boot as a dom0less domU 
> >> because it was
> >> misinterpreting the device tree version. Linux 4.14 and earlier 
> >> interpret device
> >> trees with a "/" in the root node as version 16. Xen produces a 
> >> version 17
> >> device tree, so the root node needs to be "" to work with 4.14 and 
> >> earlier Linux
> >> Kernels. Linux 4.15 and later assume that the version is 17, so this 
> >> patch does
> >> not have any impact.
> >>
> >> Please let me know if you need any more information or have 
> >> suggestions for
> >> other ways to handle this.
> > 
> > I don't understand where the version comes from. I also don't understand 
> > how you inferred that Xen is creating a version 17 device-tree.
> > 
> > Do you have link to the paragraph in the specifications?
> 
> Also, please expand what is the exact error. So we can understand 
> whether this is the right fix.
> 
> Cheers,
> 
> -- 
> Julien Grall

-- 

Hi Julien,

Thanks for the prompt response.

I said in my message that Linux was interpreting the device tree as version 16.
Looking through the code again, I realize it was being interpreted as earlier
than 16. As mentioned in Linux commit a7e4cfb0a7ca4773e7d0dd1d9c018ab27a15360e,
Linux had already broken support for FDT versions earlier than 16.
populate_node() in drivers/of/fdt.c would stop parsing the fdt at the root node
if it thought the fdt version was earlier than 16.

Xen sets the FDT version to 17 in fdt_create().

The issue I was having was that Linux panicked while initializing interrupts
because it could not find an interrupt controller. It couldn't find the
interrupt controller because it didn't process that part of the device tree.

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Stefano Stabellini 18 weeks ago
On Sat, 6 Jul 2019, Will Abele wrote:
> The 07/06/2019 18:19, Julien Grall wrote:
> > 
> > 
> > On 06/07/2019 19:17, Julien Grall wrote:
> > > 
> > > 
> > > On 06/07/2019 19:02, Will Abele wrote:
> > >> From: Will Abele <will.abele@starlab.io>
> > >>
> > >> Hi,
> > > 
> > > Hi,
> > > 
> > >> I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux 
> > >> Kernel. I had
> > >> trouble getting the 4.14 Linux Kernel to boot as a dom0less domU 
> > >> because it was
> > >> misinterpreting the device tree version. Linux 4.14 and earlier 
> > >> interpret device
> > >> trees with a "/" in the root node as version 16. Xen produces a 
> > >> version 17
> > >> device tree, so the root node needs to be "" to work with 4.14 and 
> > >> earlier Linux
> > >> Kernels. Linux 4.15 and later assume that the version is 17, so this 
> > >> patch does
> > >> not have any impact.
> > >>
> > >> Please let me know if you need any more information or have 
> > >> suggestions for
> > >> other ways to handle this.
> > > 
> > > I don't understand where the version comes from. I also don't understand 
> > > how you inferred that Xen is creating a version 17 device-tree.
> > > 
> > > Do you have link to the paragraph in the specifications?
> > 
> > Also, please expand what is the exact error. So we can understand 
> > whether this is the right fix.
> > 
> > Cheers,
> > 
> > -- 
> > Julien Grall
> 
> -- 
> 
> Hi Julien,
> 
> Thanks for the prompt response.
> 
> I said in my message that Linux was interpreting the device tree as version 16.
> Looking through the code again, I realize it was being interpreted as earlier
> than 16. As mentioned in Linux commit a7e4cfb0a7ca4773e7d0dd1d9c018ab27a15360e,
> Linux had already broken support for FDT versions earlier than 16.
> populate_node() in drivers/of/fdt.c would stop parsing the fdt at the root node
> if it thought the fdt version was earlier than 16.
> 
> Xen sets the FDT version to 17 in fdt_create().
> 
> The issue I was having was that Linux panicked while initializing interrupts
> because it could not find an interrupt controller. It couldn't find the
> interrupt controller because it didn't process that part of the device tree.

Thank you, Will! And it is great to hear that you are using dom0less :)

I couldn't find the specific reference to the spec, but I could verify
that the patch fixes the issue for Linux 4.14, while it is unneeded for
newer Linux versions (they still work with the patch). Also we already
start empty device tree using "" instead of "/" in a few other places. I
would love to have the right reference in the commit message though.

FYI we also have another instance of fdt_begin_node(fdt, "/") in
xen/arch/arm/acpi/domain_build.c that needs fixing and could be done in
this patch.

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Will Abele 18 weeks ago
The 07/08/2019 17:28, Stefano Stabellini wrote:
> On Sat, 6 Jul 2019, Will Abele wrote:
> > The 07/06/2019 18:19, Julien Grall wrote:
> > > 
> > > 
> > > On 06/07/2019 19:17, Julien Grall wrote:
> > > > 
> > > > 
> > > > On 06/07/2019 19:02, Will Abele wrote:
> > > >> From: Will Abele <will.abele@starlab.io>
> > > >>
> > > >> Hi,
> > > > 
> > > > Hi,
> > > > 
> > > >> I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux 
> > > >> Kernel. I had
> > > >> trouble getting the 4.14 Linux Kernel to boot as a dom0less domU 
> > > >> because it was
> > > >> misinterpreting the device tree version. Linux 4.14 and earlier 
> > > >> interpret device
> > > >> trees with a "/" in the root node as version 16. Xen produces a 
> > > >> version 17
> > > >> device tree, so the root node needs to be "" to work with 4.14 and 
> > > >> earlier Linux
> > > >> Kernels. Linux 4.15 and later assume that the version is 17, so this 
> > > >> patch does
> > > >> not have any impact.
> > > >>
> > > >> Please let me know if you need any more information or have 
> > > >> suggestions for
> > > >> other ways to handle this.
> > > > 
> > > > I don't understand where the version comes from. I also don't understand 
> > > > how you inferred that Xen is creating a version 17 device-tree.
> > > > 
> > > > Do you have link to the paragraph in the specifications?
> > > 
> > > Also, please expand what is the exact error. So we can understand 
> > > whether this is the right fix.
> > > 
> > > Cheers,
> > > 
> > > -- 
> > > Julien Grall
> > 
> > -- 
> > 
> > Hi Julien,
> > 
> > Thanks for the prompt response.
> > 
> > I said in my message that Linux was interpreting the device tree as version 16.
> > Looking through the code again, I realize it was being interpreted as earlier
> > than 16. As mentioned in Linux commit a7e4cfb0a7ca4773e7d0dd1d9c018ab27a15360e,
> > Linux had already broken support for FDT versions earlier than 16.
> > populate_node() in drivers/of/fdt.c would stop parsing the fdt at the root node
> > if it thought the fdt version was earlier than 16.
> > 
> > Xen sets the FDT version to 17 in fdt_create().
> > 
> > The issue I was having was that Linux panicked while initializing interrupts
> > because it could not find an interrupt controller. It couldn't find the
> > interrupt controller because it didn't process that part of the device tree.
> 
> Thank you, Will! And it is great to hear that you are using dom0less :)
> 
> I couldn't find the specific reference to the spec, but I could verify
> that the patch fixes the issue for Linux 4.14, while it is unneeded for
> newer Linux versions (they still work with the patch). Also we already
> start empty device tree using "" instead of "/" in a few other places. I
> would love to have the right reference in the commit message though.
> 
> FYI we also have another instance of fdt_begin_node(fdt, "/") in
> xen/arch/arm/acpi/domain_build.c that needs fixing and could be done in
> this patch.

Thanks, Stefano! I really appreciate all of your work on dom0less. We're very
excited to use it.

Thanks for pointing out the other instance. I'll fix that, change the commit
message to reference the spec, and send a v2 in a moment.

Thanks,
Will

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Julien Grall 19 weeks ago
Hi Will,

Anything written after -- is usually seen as a signature. This confused 
my e-mail client as it will strip the signature on reply.

On 7/6/19 10:10 PM, Will Abele wrote:
> I said in my message that Linux was interpreting the device tree as version 16.
> Looking through the code again, I realize it was being interpreted as earlier
> than 16. As mentioned in Linux commit a7e4cfb0a7ca4773e7d0dd1d9c018ab27a15360e,
> Linux had already broken support for FDT versions earlier than 16.
> populate_node() in drivers/of/fdt.c would stop parsing the fdt at the root node
> if it thought the fdt version was earlier than 16.
> 
> Xen sets the FDT version to 17 in fdt_create().

Thank you for your explanation. However, I still can't match what you 
say with a specification. Please provide a link to the specification and 
the exact paragraph.

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Will Abele 19 weeks ago
The 07/08/2019 16:18, Julien Grall wrote:
> Hi Will,
> 
> Anything written after -- is usually seen as a signature. This confused my
> e-mail client as it will strip the signature on reply.
> 
> On 7/6/19 10:10 PM, Will Abele wrote:
> > I said in my message that Linux was interpreting the device tree as version 16.
> > Looking through the code again, I realize it was being interpreted as earlier
> > than 16. As mentioned in Linux commit a7e4cfb0a7ca4773e7d0dd1d9c018ab27a15360e,
> > Linux had already broken support for FDT versions earlier than 16.
> > populate_node() in drivers/of/fdt.c would stop parsing the fdt at the root node
> > if it thought the fdt version was earlier than 16.
> > 
> > Xen sets the FDT version to 17 in fdt_create().
> 
> Thank you for your explanation. However, I still can't match what you say
> with a specification. Please provide a link to the specification and the
> exact paragraph.
> 
> Cheers,
> 
> -- 
> Julien Grall
Hi Julien,

Sorry about my email issues. I'm still getting used to using Mutt.

The Device Tree specification is here:
https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2/devicetree-specification-v0.2.pdf.

Section 2.2.1 paragraph 5 specifies that the root node does not have a node name
or a unit address. Furthermore, a "/" does not appear in the list of valid node
name characters in table 2.1.

There's an example of creating an empty device tree using "" as the root node
name in xen/common/libfdt/fdt_empty_tree.c.

Thanks,
Will

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

Re: [Xen-devel] [PATCH 0/1] Dom0less guest device tree format

Posted by Viktor Mitin 19 weeks ago
Hi All,

Please be aware that I can confirm the issue.
Current dom0less domU code needs to be fixed.
The issue has been reproduced with several kernel images 4.14.75.
Linux kernel 4.15 image works well without this fix.
Kernel images 4.14.75 and 4.15 works fine with this fix.

Thanks

On Sun, Jul 7, 2019 at 12:12 AM Will Abele <will.abele@starlab.io> wrote:
>
> The 07/06/2019 18:19, Julien Grall wrote:
> >
> >
> > On 06/07/2019 19:17, Julien Grall wrote:
> > >
> > >
> > > On 06/07/2019 19:02, Will Abele wrote:
> > >> From: Will Abele <will.abele@starlab.io>
> > >>
> > >> Hi,
> > >
> > > Hi,
> > >
> > >> I've been using dom0less Xen on the Hikey 960 with a 4.14 Linux
> > >> Kernel. I had
> > >> trouble getting the 4.14 Linux Kernel to boot as a dom0less domU
> > >> because it was
> > >> misinterpreting the device tree version. Linux 4.14 and earlier
> > >> interpret device
> > >> trees with a "/" in the root node as version 16. Xen produces a
> > >> version 17
> > >> device tree, so the root node needs to be "" to work with 4.14 and
> > >> earlier Linux
> > >> Kernels. Linux 4.15 and later assume that the version is 17, so this
> > >> patch does
> > >> not have any impact.
> > >>
> > >> Please let me know if you need any more information or have
> > >> suggestions for
> > >> other ways to handle this.
> > >
> > > I don't understand where the version comes from. I also don't understand
> > > how you inferred that Xen is creating a version 17 device-tree.
> > >
> > > Do you have link to the paragraph in the specifications?
> >
> > Also, please expand what is the exact error. So we can understand
> > whether this is the right fix.
> >
> > Cheers,
> >
> > --
> > Julien Grall
>
> --
>
> Hi Julien,
>
> Thanks for the prompt response.
>
> I said in my message that Linux was interpreting the device tree as version 16.
> Looking through the code again, I realize it was being interpreted as earlier
> than 16. As mentioned in Linux commit a7e4cfb0a7ca4773e7d0dd1d9c018ab27a15360e,
> Linux had already broken support for FDT versions earlier than 16.
> populate_node() in drivers/of/fdt.c would stop parsing the fdt at the root node
> if it thought the fdt version was earlier than 16.
>
> Xen sets the FDT version to 17 in fdt_create().
>
> The issue I was having was that Linux panicked while initializing interrupts
> because it could not find an interrupt controller. It couldn't find the
> interrupt controller because it didn't process that part of the device tree.
>
> Thanks,
> Will
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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