xen/arm: How to hide console UART from dom0?

xen/arm: How to hide console UART from dom0?

[Ian Campbell]

Current mainline Xen crashes for me during dom0 boot because the console
UART is exposed to dom0 in the DTB and nothing is mapped there, which
causes it to fault trying to access it.

My, unsuitable for upstream, local hack is:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0abacda..5d4916c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -231,6 +231,7 @@ static int fdt_next_dom0_node(const void *fdt, int node,
                               int *depth_out)
 {
     int depth = *depth_out;
+    const char *name;
 
     while ( (node = fdt_next_node(fdt, node, &depth)) &&
             node >= 0 && depth >= 0 )
@@ -250,7 +251,16 @@ static int fdt_next_dom0_node(const void *fdt, int node,
                                        "xen,multiboot-module" ) == 0 )
             continue;
 
+        name = fdt_get_name(fdt, node, NULL);
+        if (!strcmp(name, "uart@0c0000"))
+        {
+            printk("Skipping %s\n", name);
+            continue;
+        }
+
         /* We've arrived at a node which dom0 is interested in. */
+        printk("Node %s to dom0\n", name);
+
         break;
     }
 
I tried seeing if I could remember the name of the console DT device but
in dt_uart_init I get:
        dt_node_full_name
        => /smb/motherboard/iofpga@3,00000000/uart@0c000
        dt_node_name => uart
Neither of which match the required "uart@0c000" which
fdt_next_dom0_node has in its hand.

Julien, I know you have longer term plans to create dom0's device tree
from Xen's unflattened device tree using the used_by field but I suppose
that won't be happening for 4.3 at this stage? Is there a better short
term hack we can make here? How do you work around this issue?

Ian.

Re: xen/arm: How to hide console UART from dom0?

[Ian Campbell]

On Fri, 2013-05-31 at 12:07 +0100, Ian Campbell wrote:
> Current mainline Xen crashes for me during dom0 boot because the console
> UART is exposed to dom0 in the DTB and nothing is mapped there, which
> causes it to fault trying to access it.
> 
> My, unsuitable for upstream, local hack is:
[...]
> 
> [...]Is there a better short term hack we can make here?

Still hacky, but less so than my current hack, would be adding a
"dom0_dtb_hide" hypervisor command line parameter. It's a hack but at
least it is a little more generic...

Ian.

Re: xen/arm: How to hide console UART from dom0?

[Julien Grall]

On 05/31/2013 12:07 PM, Ian Campbell wrote:

> Current mainline Xen crashes for me during dom0 boot because the console
> UART is exposed to dom0 in the DTB and nothing is mapped there, which
> causes it to fault trying to access it.
> 
> My, unsuitable for upstream, local hack is:
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 0abacda..5d4916c 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -231,6 +231,7 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>                                int *depth_out)
>  {
>      int depth = *depth_out;
> +    const char *name;
>  
>      while ( (node = fdt_next_node(fdt, node, &depth)) &&
>              node >= 0 && depth >= 0 )
> @@ -250,7 +251,16 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>                                         "xen,multiboot-module" ) == 0 )
>              continue;
>  
> +        name = fdt_get_name(fdt, node, NULL);
> +        if (!strcmp(name, "uart@0c0000"))
> +        {
> +            printk("Skipping %s\n", name);
> +            continue;
> +        }
> +
>          /* We've arrived at a node which dom0 is interested in. */
> +        printk("Node %s to dom0\n", name);
> +
>          break;
>      }
>  
> I tried seeing if I could remember the name of the console DT device but
> in dt_uart_init I get:
>         dt_node_full_name
>         => /smb/motherboard/iofpga@3,00000000/uart@0c000
>         dt_node_name => uart
> Neither of which match the required "uart@0c000" which
> fdt_next_dom0_node has in its hand.

By default, the part after @ is removed. If needed, it's easily to
provide a pointer to "uart@0c000" but I'm not sure it's usefull for us.

> Julien, I know you have longer term plans to create dom0's device tree
> from Xen's unflattened device tree using the used_by field but I suppose
> that won't be happening for 4.3 at this stage? Is there a better short
> term hack we can make here? How do you work around this issue?


Right. It's possible to add a property: status = "disabled"; on the
specific node (here the UART). Linux will interpret this property and
won't use the node.
For the moment, this property is not used by Xen so you can directly add
it on your DTS.

-- 
Julien

Re: xen/arm: How to hide console UART from dom0?

[Ian Campbell]

On Fri, 2013-05-31 at 13:50 +0100, Julien Grall wrote:
> > I tried seeing if I could remember the name of the console DT device but
> > in dt_uart_init I get:
> >         dt_node_full_name
> >         => /smb/motherboard/iofpga@3,00000000/uart@0c000
> >         dt_node_name => uart
> > Neither of which match the required "uart@0c000" which
> > fdt_next_dom0_node has in its hand.
> 
> By default, the part after @ is removed. If needed, it's easily to
> provide a pointer to "uart@0c000" but I'm not sure it's usefull for us.

Other than for this purpose I expect not, lets not worry about it.

> > Julien, I know you have longer term plans to create dom0's device tree
> > from Xen's unflattened device tree using the used_by field but I suppose
> > that won't be happening for 4.3 at this stage? Is there a better short
> > term hack we can make here? How do you work around this issue?
> 
> 
> Right. It's possible to add a property: status = "disabled"; on the
> specific node (here the UART). Linux will interpret this property and
> won't use the node.
> For the moment, this property is not used by Xen so you can directly add
> it on your DTS.

Thanks, this will suffice as long as we do proper construction of the
dom0 fdt before making Xen obey this property ;-)

Ian.