Re: dom0 LInux 5.8-rc5 kernel failing to initialize cooling maps for Allwinner H6 SoC

[Amit Tomer]

Hi,

> I remember this discussion. The problem was that the PMU is using
> per-CPU interrupts. Xen is not yet able to handle PPIs as they often
> requires more context to be saved/restored (in this case the PMU context).
>
> There was a proposal to look if a device is using PPIs and just remove
> them from the Device-Tree. Unfortunately, I haven't seen any official
> submission for this patch.

But we have this patch that remove devices using PPIs
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9b1a31922ac066ef0dffe36ebd6a6ba016567d69

Thanks
-Amit

Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform

[Amit Tomer]

Hi

>
> What are the consequences to change the interrupt parent?

I am not entirely sure about it at the moment but looks like it
controllers power domain
for various devices like GPU, VPU and OTG etc.

So, we may not be able to support these devices for XEN domains ?

Also, this IP is not present on other i.MX8 platforms, for instance iMX8QM.

> >
> > The patches has been tested booting DOM0 with ramfs.
>
> I don't think this is enough to claim support for Xen on the I.MX8M platform.
> What I don't want to end up is having yet another UART driver to maintain in 
> Xen
> but the platform is still unusable.
>
> You should at least be able to boot multiple domains and use a fully fledge
> distro (yocto, Debian...) from a mass storage (and possibly network).
>
Yeah, I can understand this and would try to work on it (but not sure
when can I have access
to H/W).

Thanks,
Amit

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

Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform

[Amit Tomer]

Hi Nate , Hi Julien,

>
> Amit,
>
> Have you checked out the NXP Xen fork?
>
> https://source.codeaurora.org/external/imx/imx-xen/
>
> While the work there hasn't been upstreamed yet, the support for the 
> iMX8QM
> (QuadMax) is fairly complete.  There are some important differences between 
> the
> iMX8M and that SoC beyond those you've noted (no A72 cluster, no SMMU, and no
> System Control Unit (SCU)), but it might solve some of the issues you've been
> running into or avoid yet unknown issues when you attempt to boot a guest 
> domain.

I looked around the work done for iMX8QM but the UART IP used on
i.MX8MQ is completely different than
that used on i.MXQM.

The initial agenda of this series is to get particular uart
driver(used on i.IMX8MQ) in first and then
start booting domUs.

Thanks,
-Amit

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

Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform

[Amit Tomer]

Hi,

Sorry for the late reply.

> I have seen multiple threads from you pointing at issues on the IMX.8. Have 
> they
> been resolved? Is this series enough to get Xen and Dom0 booting on the NXP
> platform?

Yeah, most of issues are resolved now and mainline DTS is used to
bring XEN on this i.MX8 platform.

Though there is small change that comment out GPC (which is used root
interrupt parent) and instead use GIC
is done in DTS.

The patches has been tested booting DOM0 with ramfs.

Thanks,
-Amit

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

Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform

[Amit Tomer]

Hi,

On Sat, Jun 8, 2019 at 1:46 AM Amit Singh Tomar  wrote:
>
> This series tries to enable XEN booting on i.MX 8MQuad Applications 
> Processors[1].
>
> Patch-set includes driver for UART controller found on i.MX8MQ SoC and debug 
> code
> for earlyprintk support.
>
Gentle Ping.

Thanks
-Amit

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

Re: [Xen-devel] [PATCH] xen/arm: Black list everything with a PPI

[Amit Tomer]

Hi,

On Wed, May 29, 2019 at 11:17 PM Julien Grall  wrote:
>
> Hi Amit,
>
> Just a quick follow-up. Is there any plan to send a new version of this patch?
>
Sorry for late on this, I would be able to send it(with a comment for
PPI's range) on coming weekend.

Thanks,
-Amit

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

Re: [Xen-devel] [PATCH] xen/arm: Black list everything with a PPI

[Amit Tomer]

Hello,

Thanks for having a look at it.

On Thu, May 16, 2019 at 12:25 AM Oleksandr  wrote:
>
>
> On 03.05.19 20:02, Amit Singh Tomar wrote:
>
> Hi, Amit
>
> > XEN should not forward PPIs to Dom0 as it only support SPIs.
> > One of solution to this problem is to skip any device that
> > uses PPI source completely while building domain itself.
> >
> > This patch goes through all the interrupt sources of device and skip it
> > if one of interrupt source is PPI. It fixes XEN boot on i.MX8MQ by
> > skipping PMU node.
> >
> > Suggested-by:  Julien Grall 
> > Signed-off-by: Amit Singh Tomar 
> > ---
> >  * This replaces following patch.
> >https://patchwork.kernel.org/patch/10899881/
> > ---
> >   xen/arch/arm/domain_build.c | 16 +++-
> >   1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index d983677..8f54472 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1353,7 +1353,7 @@ static int __init handle_node(struct domain *d, 
> > struct kernel_info *kinfo,
> >   { /* sentinel */ },
> >   };
> >   struct dt_device_node *child;
> > -int res;
> > +int res, i, nirq, irq_id;
> >   const char *name;
> >   const char *path;
> >
> > @@ -1399,6 +1399,20 @@ static int __init handle_node(struct domain *d, 
> > struct kernel_info *kinfo,
> >   return 0;
> >   }
> >
> > +/* Skip the node, using PPI source */
> > +nirq = dt_number_of_irq(node);
> > +
> > +for ( i = 0 ; i < nirq ; i++ )
> > +{
> > +irq_id = platform_get_irq(node, i);
>
> Do we need to do something here if platform_get_irq() returns -1?

Yeah, I should have done it. some think like following:
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/domain_build.c;h=d9836779d17c90e84b94ba32e4a20f028189fc5b;hb=HEAD#l1284

> > +
> > +if ( irq_id >= 16 && irq_id < 32 )
> > +{
> > +dt_dprintk(" Skip node with (PPI source)\n");
> > +return 0;
> > +}
> > +}
> > +
> >   /*
> >* Xen is using some path for its own purpose. Warn if a node
> >* already exists with the same path.
>
> Patch looks good. Although R-Car H3 seems to not use PPIs for PMU, I
> have tested your patch just to be sure it wouldn't skip anything by a
> mistake)

Ok, Thanks for testing it. I would resend it with error condition check.

-Thanks
Amit.

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

Re: [Xen-devel] [PATCH] xen/arm: Black list everything with a PPI

[Amit Tomer]

Sorry Just sent the wrong patch , Please ignore this.

On Fri, May 3, 2019 at 10:13 PM Amit Singh Tomar  wrote:
>
> XEN should not forward PPIs to Dom0 as it only support SPIs.
> One of solution to this problem is to skip any device that
> uses PPI source completely while building domain itself.
>
> This patch goes through all the interrupt sources of device and skip it
> if one of interrupt source is PPI. It fixes XEN boot on i.MX8MQ by
> skipping PMU node.
>
> Suggested-by:  Julien Grall 
> Signed-off-by: Amit Singh Tomar 
> ---
> * This replaces following patch.
>   https://patchwork.kernel.org/patch/10899881/
> ---
>  xen/arch/arm/domain_build.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d983677..0ae54db 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1334,6 +1334,7 @@ static int __init handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  DT_MATCH_COMPATIBLE("arm,cortex-a15-pmu"),
>  DT_MATCH_COMPATIBLE("arm,cortex-a53-edac"),
>  DT_MATCH_COMPATIBLE("arm,armv8-pmuv3"),
> +DT_MATCH_COMPATIBLE("arm,cortex-a53-pmu"),
>  DT_MATCH_PATH("/cpus"),
>  DT_MATCH_TYPE("memory"),
>  /* The memory mapped timer is not supported by Xen. */
> @@ -1353,7 +1354,7 @@ static int __init handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  { /* sentinel */ },
>  };
>  struct dt_device_node *child;
> -int res;
> +int res, i, nirq, irq_id;
>  const char *name;
>  const char *path;
>
> @@ -1399,6 +1400,20 @@ static int __init handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  return 0;
>  }
>
> +/* Skip the node, using PPI source */
> +nirq = dt_number_of_irq(node);
> +
> +for ( i = 0 ; i < nirq ; i++ )
> +{
> +irq_id = platform_get_irq(node, i);
> +
> +if ( irq_id >= 16 && irq_id < 32 )
> +{
> +dt_dprintk(" Skip node with (PPI source)\n");
> +return 0;
> +}
> +}
> +
>  /*
>   * Xen is using some path for its own purpose. Warn if a node
>   * already exists with the same path.
> --
> 2.7.4
>

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

Re: [Xen-devel] [PATCH] xen/arm: Blacklist PMU with "arm, cortex-a53-pmu"

[Amit Tomer]

Hello,
>
> The proper way is to detect PPI before hand and completely skip the node if 
> any.

I tried the following change:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..a9ecfed 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1353,7 +1353,7 @@ static int __init handle_node(struct domain *d,
struct kernel_info *kinfo,
 { /* sentinel */ },
 };
 struct dt_device_node *child;
-int res;
+int res, irq_id;
 const char *name;
 const char *path;

@@ -1399,6 +1399,16 @@ static int __init handle_node(struct domain *d,
struct kernel_info *kinfo,
 return 0;
 }

+/*Skip the node, using PPI source */
+irq_id = platform_get_irq(node, 0);
+
+if ( irq_id > 16 && irq_id < 32 )
+{
+dt_dprintk(" Skip node with (PPI source)\n");
+return 0;
+}
+
+

After booting dom0, don't see PMU node is getting generated(its
skipped completely now).

Thanks,
-Amit.



> Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Blacklist PMU with "arm, cortex-a53-pmu"

[Amit Tomer]

Hello,

> Could we instead try to automatically blacklist any device using PPI?

Just tested following change:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..0c82976 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1289,6 +1289,10 @@ static int __init handle_device(struct domain
*d, struct dt_device_node *dev,
 return res;
 }

+/* Don't process device using PPI source */
+if ( res > 16 && res < 32)
+return 0;
+
 res = map_irq_to_domain(d, res, need_mapping, dt_node_name(dev));
 if ( res )
 return res;

Would it be Ok ?

Thanks,
-Amit

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

Re: [Xen-devel] Arm boot regression with Xen 4.12

[Amit Tomer]

Hello,

On Fri, Mar 22, 2019 at 5:05 PM Amit Tomer  wrote:
>
> Hi,
>
>
> > I am wondering if you had time to bisect the issue?
> >
> > We are releasing Xen 4.12 soon so we need to make the decision whether this
> > should be fixed after (and backport it) or before.

Don't see this crash if I chose to have different load addresses(Load
kernel at 2 MB aligned address).
For instance, using

"setenv xen_addr_r 0x4048 ;setenv fdt_addr_r 0x4300;setenv
kernel_addr_r 0x4100"
 instead of
"setenv xen_addr_r 0x4200 ;setenv fdt_addr_r 0x4300;setenv
kernel_addr_r 0x4048"

Allow it boot properly(Tested it with 4.13).

Thanks
-Amit

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

Re: [Xen-devel] [PATCH] xen/arm: Blacklist PMU with "arm, cortex-a53-pmu"

[Amit Tomer]

Hello,

> After talking via IRC, the problem is PPIs, that this platform uses for
> PMU interrupts. When Xen tries to setup the IRQ forwarding for Dom0 for
> this device, it fails because it only supports forwarding SPIs.
> So interestingly we erroneously forwarded A53 PMUs (those that are
> described by that particular compatible string only) to Dom0 for quite a
> while, but nobody noticed (or cared).
>
> Amit, please adjust the commit message accordingly.
>
Ok but original commit "d45e9b7c53428a2aa4d067927e7ef5e30783fb8b" that blacklist
PMU's clearly states that issue is due to PPI and that can not be
routed to guest.

I thought, This patch is just continuation of same.

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v3] xen/arm: Add Amlogic Meson SoCs earlyprintk support

[Amit Tomer]

Hello,

> Do all the firmware existing for this platform initialize the UART?

U-boot does also initialize the uart for this platform.
https://github.com/u-boot/u-boot/blob/master/drivers/serial/serial_meson.c#L44

Thanks,
-Amit

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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add MESON UART driver for Amlogic Meson SoCs

[Amit Tomer]

Hello,

On Tue, Apr 9, 2019 at 3:09 PM Julien Grall  wrote:
>
> Hi,
>
> On 02/04/2019 21:01, André Przywara wrote:
> > On 21/03/2019 10:25, Amit Singh Tomar wrote:
> >> This patch adds driver for UART controller present on Amlogic Meson
> >> SoCs and it has been tested on Nanopi K2 board based on S905 SoC.
> >>
> >> Controller registers defination is taken from Linux 4.20.
> >> https://github.com/torvalds/linux/blob/v4.20-rc1/drivers/tty/serial/meson_uart.c
> >>
> >> Signed-off-by: Amit Singh Tomar 
> >
> > Thanks for the changes!
> >
> > Reviewed-by: Andre Przywara 
>
> Acked-by: Julien Grall 

Thanks.

> I have committed this patch and the following patch. Please resend the first
> patch with the comments addressed.

Is it the patch with following subject:
[PATCH v2 1/3] xen/arm: Add Amlogic Meson SoCs earlyprintk support

Really, couldn't find any comments over there.

-Amit.

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

Re: [Xen-devel] [PATCH v1 1/2] xen/arm: Add Amlogic Meson SoCs earlyprintk support

[Amit Tomer]

Hi,


> Apart from this and the unneeded addition to early-printk.txt (which
> Julien mentioned already) this looks now correct to me.

I was wondering, if it's a good idea to have
"CONFIG_EARLY_PRINTK=meson,0xc81004c0"
documented in Rules.mk.

It would give fair idea to someone who is new to Xen, how to compile
meson with early printk support ?

Thanks
-Amit.

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

Re: [Xen-devel] Arm boot regression with Xen 4.12

[Amit Tomer]

Hi,

> Could you give a try to the below patch?
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 01ae20..2c34138bbd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1139,7 +1139,7 @@ void free_init_memory(void)
>  *(p + i) = insn;
>
>  set_pte_flags_on_range(__init_begin, len, mg_clear);
> -init_domheap_pages(pa, pa + len);
> +dt_unreserved_regions(pa, pa + len, init_domheap_pages, 0);
>  printk("Freed %ldkB init memory.\n", 
> (long)(__init_end-__init_begin)>>10);
>  }
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 444857a967..8dbc4f819b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -764,18 +764,18 @@ void __init start_xen(unsigned long boot_phys_offset,
>"Please check your bootloader.\n",
>fdt_paddr);
>
> -fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
> -
> -cmdline = boot_fdt_cmdline(device_tree_flattened);
> -printk("Command line: %s\n", cmdline);
> -cmdline_parse(cmdline);
> -
>  /* Register Xen's load address as a boot module. */
>  xen_bootmodule = add_boot_module(BOOTMOD_XEN,
>   (paddr_t)(uintptr_t)(_start + boot_phys_offset),
>   (paddr_t)(uintptr_t)(_end - _start + 1), false);
>  BUG_ON(!xen_bootmodule);
>
> +fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
> +
> +cmdline = boot_fdt_cmdline(device_tree_flattened);
> +printk("Command line: %s\n", cmdline);
> +cmdline_parse(cmdline);
> +
>  setup_pagetables(boot_phys_offset);
>
>  setup_mm(fdt_paddr, fdt_size);
>


I tried the above patch but still see the same crash:

tarting kernel ...

- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: 4200 - 42120d81 Xen
(XEN) MODULE[1]: be51 - be51d000 Device Tree
(XEN) MODULE[2]: 4048 - 4268 Kernel
(XEN)  RESVD[0]: 4300 - 4300d000
(XEN)  RESVD[1]: be51 - be51d000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1024M
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
 Xen 4.13-unstable
(XEN) Xen version 4.13-unstable (atomar@) (aarch64-linux-gnu-gcc
(Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Tue Mar 19 19:14:9
(XEN) Latest ChangeSet: Tue Feb 12 18:33:30 2019 + git:1e780ef-dirty
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN)   Processor Features: 0100 
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN)   gic_dist_addr=0x003880
(XEN)   gic_maintenance_irq=25
(XEN)   gic_rdist_stride=0
(XEN)   gic_rdist_regions=1
(XEN)   redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on 

Re: [Xen-devel] Running XEN on imx8mq

[Amit Tomer]

Hello,

> It will be difficult to help without any log. You probably want to try with
> Stefano series instead. However ...

If we comment out GPU node(gpu@3800) , we don't see this issue and
Dom0 kernel is
loaded into memory but we following crash:

Starting kernel ...

- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: be511000 - be51d000 Device Tree
(XEN) MODULE[1]: 4048 - 4268 Kernel
(XEN)  RESVD[0]: 4300 - 4300c000
(XEN)  RESVD[1]: be511000 - be51d000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1024M
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
 Xen 4.12.0-rc
(XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Mon Mar 18
20:31:35 I9
(XEN) Latest ChangeSet: Tue Mar 5 12:48:52 2019 + git:4deeaf2
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN)   Processor Features: 0100 
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN)   gic_dist_addr=0x003880
(XEN)   gic_maintenance_irq=25
(XEN)   gic_rdist_stride=0
(XEN)   gic_rdist_regions=1
(XEN)   redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU1: Found redistributor in region 0 @4003a000
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU2: Found redistributor in region 0 @4005a000
(XEN) Adding cpu 2 to runqueue 0
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000
(XEN) Adding cpu 3 to runqueue 0
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) I/O virtualisation disabled
(XEN) build-id: e89d2543bdd91038674917e9d0be5b56a3ef0fd7
(XEN) alternatives: Patching with alt table 002abbd8 -> 002ac220
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading Domd0 kernel from boot module @ 4048
(XEN) Allocating 1:1 mappings totalling 1024MB for dom0:
(XEN) BANK[0] 0x006000-0x00a000 (1024MB)
(XEN) Grant table range: 0x004200-0x004204
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 4048 to 6008-6228
(XEN) Loading dom0 DTB to 0x6800-0x6800b99e
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) 

Re: [Xen-devel] Running XEN on imx8mq

[Amit Tomer]

> It will be difficult to help without any log. You probably want to try with
> Stefano series instead. However ...

Yeah, tried Stefano series as well but show same message:


Starting kernel ...

- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) fdt: node `linux,cma': missing `reg' property
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: be51 - be51d000 Device Tree
(XEN) MODULE[1]: 4048 - 4268 Kernel
(XEN)  RESVD[0]: 4300 - 4300d000
(XEN)  RESVD[1]: be51 - be51d000
(XEN)
(XEN) Command line: console=dtuart dom0_mem=2048M
(XEN) Placing Xen at 0xbfe0-0xc000
(XEN) Update BOOTMOD_XEN from 4200-42118d81 =>
bfe0-bff18d81
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
 Xen 4.12-unstable
(XEN) Xen version 4.12-unstable (amit@) (aarch64-linux-gnu-gcc (Linaro
GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Mon Mar 18 17:49:9
(XEN) Latest ChangeSet: Thu Mar 7 13:22:10 2019 -0800 git:62617af
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN)   Processor Features: 0100 
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN)   gic_dist_addr=0x003880
(XEN)   gic_maintenance_irq=25
(XEN)   gic_rdist_stride=0
(XEN)   gic_rdist_regions=1
(XEN)   redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU1: Found redistributor in region 0 @4003a000
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU2: Found redistributor in region 0 @4005a000
(XEN) Adding cpu 2 to runqueue 0
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000
(XEN) Adding cpu 3 to runqueue 0
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) I/O virtualisation disabled
(XEN) build-id: 1635738d31cfca03ae48949e8cd29221cdfe458c
(XEN) alternatives: Patching with alt table 002aba18 -> 002ac018
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 4048
(XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
(XEN) WARNING: Failed to allocate requested dom0 memory. 224MB unallocated
(XEN) BANK[0] 0x004400-0x00b600 (1824MB)
(XEN) Grant table range: 0x00bfe0-0x00bfe4
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) 

Re: [Xen-devel] Running XEN on imx8mq

[Amit Tomer]

Hello,

> The tree you are using is dirty. What did you change?

Just added the imx8mq specific debug so that we can see early prints from XEN,
>
> [..]
>
> > (XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000
> > (XEN) Adding cpu 3 to runqueue 0
> > (XEN) CPU 3 booted.
> > (XEN) Brought up 4 CPUs
> > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> > (XEN) I/O virtualisation disabled
> > (XEN) build-id: d884da2ad279978f5b120cd02aca4034d898f133
> > (XEN) alternatives: Patching with alt table 002abbf8 -> 
> > 002ac240
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Loading Domd0 kernel from boot module @ 4048
> > (XEN) Allocating 1:1 mappings totalling 1024MB for dom0:
> > (XEN) BANK[0] 0x006000-0x00a000 (1024MB)
> > (XEN) Grant table range: 0x004200-0x004204
> > (XEN) Allocating PPI 16 for event channel interrupt
> > (XEN) Loading zImage from 4048 to 
> > 6008-6188
> > (XEN) dom0 IPA 0x6008
> > (XEN) P2M @ 000801bff4a0 mfn:0xbffcc
> > (XEN) Using concatenated root table 0
> > (XEN) 1ST[0x1] = 0x02c046fd
> > (XEN) 
> > (XEN) Panic on CPU 0:
> > (XEN) Unable to copy the kernel in the hwdom memory
> > (XEN) 
>
> This looks like the same problem on encounter on the RCar. I.e the
> reserved-memory regions are not carved from xenheap pool.

This is the first thing we tried (removing reserved node from DTS file) but
it didn't work :(

Just wondering here, if it has some thing to do with following commit ?

https://source.codeaurora.org/external/imx/imx-xen/commit/?h=imx_4.14.62_1.0.0_beta=502413d9240169068cde9d73e0d4aa0675978bc5

-Thanks.
Amit

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

[Xen-devel] Running XEN on imx8mq

[Amit Tomer]

Hi,

Trying to run XEN on imx8mq which is different from imx8qm in term of
UART controller IP(attached is the debug code).

DTS used for host is :
https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_4.9.x_2.0.0_ga/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi

But , I see following issue:

=> setenv xen_addr_r 0x4200 ;setenv fdt_addr_r 0x4300;setenv
kernel_addr_r 0x4048
=> setenv fdt_high 0x;fdt addr $fdt_addr_r;fdt resize
=> setenv xen_bootargs console=dtuart dom0_mem=1024M
=> setenv dom0_bootargs console=hvc0,115200n8 earlycon=xenboot debug
clk_ignore_unused root=/dev/mmcblk1p1 rw rootwait
=> fdt set /chosen xen,xen-bootargs \"$xen_bootargs\";
=> fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\";fdt mknode
/chosen modules
=> fdt set /chosen/modules '#address-cells' <1>;fdt set
/chosen/modules '#size-cells' <1>;fdt mknode /chosen/modules module@0
=> fdt set /chosen/modules/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
=> fdt set /chosen/modules/module@0 reg < $kernel_addr_r 0x180 >
=>
=> booti ${xen_addr_r} - ${fdt_addr_r}
## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
   reserving fdt memory region: addr=4300 size=d000
   Loading Device Tree to be51, end be51 ... OK

Starting kernel ...

- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: be51 - be51d000 Device Tree
(XEN) MODULE[1]: 4048 - 41c8 Kernel
(XEN)  RESVD[0]: 4300 - 4300d000
(XEN)  RESVD[1]: be51 - be51d000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1024M
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
 Xen 4.12.0-rc
(XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Mon Mar 18
12:30:38 I9
(XEN) Latest ChangeSet: Tue Mar 5 12:48:52 2019 + git:4deeaf2-dirty
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN)   Processor Features: 0100 
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN)   gic_dist_addr=0x003880
(XEN)   gic_maintenance_irq=25
(XEN)   gic_rdist_stride=0
(XEN)   gic_rdist_regions=1
(XEN)   redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU1: Found redistributor in region 0 @4003a000
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU2: Found redistributor in region 0 @4005a000
(XEN) Adding cpu 2 to runqueue 0
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- 

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

>
> Starting kernel ...
>
> - UART enabled -
> - CPU  booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) Initrd 7640-77a230f7
> (XEN) RAM: 4800 - bfff
> (XEN) RAM: 0005 - 00057fff
> (XEN) RAM: 0006 - 00067fff
> (XEN) RAM: 0007 - 00077fff
> (XEN)
> (XEN) MODULE[0]: 4800 - 48014080 Device Tree
> (XEN) MODULE[1]: 7640 - 77a230f7 Ramdisk
> (XEN) MODULE[2]: 7a00 - 7c00 Kernel
> (XEN) MODULE[3]: 7c00 - 7c01 XSM
> (XEN)  RESVD[0]: 4800 - 48014000
> (XEN)  RESVD[1]: 7640 - 77a230f7
> (XEN)
> (XEN) Command line: dom0_mem=256M console=dtuart dtuart=serial0
> dom0_max_vcpus=4 bootscrub=0 loglvl=all
> (XEN) Placing Xen at 0x00077fe0-0x00078000
> (XEN) Update BOOTMOD_XEN from 7808-781b2d81 =>
> 00077fe0-00077ff32d81
> (XEN) Domain heap initialised
> (XEN) Booting using Device Tree
> (XEN) Platform: Generic System
> (XEN) Looking for dtuart at "serial0", options ""
> (XEN) Unable to initialize dtuart: -9
> (XEN) Bad console= option 'dtuart'
>   *Xen 4.9.1-pre*
> (XEN) Xen version 4.9.1-pre (otyshchenko@) (aarch64-poky-linux-gcc (GCC)
> 7.3.0) debug=y  Tue Mar  5 20:57:55 EET 2019
> (XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty
> (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
> (XEN) 64-bit Execution:
> (XEN)   Processor Features:  
> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> (XEN) Extensions: FloatingPoint AdvancedSIMD
> (XEN)   Debug Features: 10305106 
> (XEN)   Auxiliary Features:  
> (XEN)   Memory Model Features: 1124 
> (XEN)   ISA Features:  00011120 
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 0131:00011011
> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN)   Debug Features: 03010066
> (XEN)   Auxiliary Features: 
> (XEN)   Memory Model Features: 10201105 4000 0126 02102211
> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
> (XEN) Using PSCI-1.0 for SMP bringup
> (XEN) SMP: Allowing 8 CPUs
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
> (XEN) GICv2 initialization:
> (XEN) gic_dist_addr=f101
> (XEN) gic_cpu_addr=f102
> (XEN) gic_hyp_addr=f104
> (XEN) gic_vcpu_addr=f106
> (XEN) gic_maintenance_irq=25
> (XEN) GICv2: Adjusting CPU interface base to 0xf102f000
> (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
> (XEN) XSM Framework v1.0.0 initialized
> (XEN) xsm: Policy len = 0x0001 start at 0x7c00
> (XEN) Flask: 128 avtab hash slots, 280 rules.
> (XEN) Flask: 128 avtab hash slots, 280 rules.
> (XEN) Flask:  4 users, 3 roles, 38 types, 2 bools
> (XEN) Flask:  12 classes, 280 rules
> (XEN) Flask:  Starting in enforcing mode.
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Allocated console ring of 64 KiB.
> (XEN) Bringing up CPU1
> - CPU 0001 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 1 booted.
> (XEN) Bringing up CPU2
> - CPU 0002 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 2 booted.
> (XEN) Bringing up CPU3
> - CPU 0003 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 3 booted.
> (XEN) Bringing up CPU4
> - CPU 0100 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 4 booted.
> (XEN) Bringing up CPU5
> - CPU 0101 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 5 booted.
> (XEN) Bringing up CPU6
> - CPU 0102 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 6 booted.
> (XEN) Bringing up CPU7
> - CPU 0103 booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 7 booted.
> (XEN) Brought up 8 CPUs
> (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
> 

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

[Amit Tomer]

Hi,

> It might be possible to rework Dom0 memory allocation to limit the
> damage or even re-order the binary in memory. Amit, could you post the
> full Xen log with earlyprintk enabled?

Please find XEN logs :

[  229.769854] Starting kernel ...
[  229.773120]
- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4800 - 7fff
(XEN) RAM: 0005 - 00053fff
(XEN) RAM: 0006 - 00063fff
(XEN) RAM: 0007 - 00073fff
(XEN)
(XEN) MODULE[0]: 7d70f000 - 7d722000 Device Tree
(XEN) MODULE[1]: 7a00 - 7b80 Kernel
(XEN)  RESVD[0]: 4a00 - 4a013000
(XEN)  RESVD[1]: 7d70f000 - 7d722000
(XEN)
(XEN) Command line: console=dtuart dom0_mem=2048M
(XEN) Placing Xen at 0x00073fe0-0x00074000
(XEN) Update BOOTMOD_XEN from 4800-48118d81 =>
00073fe0-00073ff18d81
(XEN) PFN compression on bits 19...19
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "serial0", options "115200n8"
(XEN) WARNING: UART configuration is not supported
 Xen 4.12-unstable
(XEN) Xen version 4.12-unstable (amit@) (aarch64-linux-gnu-gcc (Linaro
GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Fri Mar  8
13:09:49 IST 2019
(XEN) Latest ChangeSet: Thu Mar 7 13:22:10 2019 -0800 git:62617af
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(XEN) 64-bit Execution:
(XEN)   Processor Features:  
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1124 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.1
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f101
(XEN) gic_cpu_addr=f102
(XEN) gic_hyp_addr=f104
(XEN) gic_vcpu_addr=f106
(XEN) gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 2 to runqueue 0
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 3 to runqueue 0
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
- CPU 0100 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU4 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
(XEN) disable cpu (see big.LITTLE.txt under docs/).
(XEN) CPU4 never came online
(XEN) Failed to bring up CPU 4 (error -5)
(XEN) Bringing up CPU5
- CPU 0101 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU5 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
(XEN) disable cpu (see big.LITTLE.txt under docs/).
(XEN) CPU5 never came online
(XEN) Failed to bring up CPU 5 (error -5)
(XEN) Bringing up CPU6
- CPU 0102 booting -
- 

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

[Amit Tomer]

Hi,

> Yes, you are right. I made a couple of quick fixes for this issue and
> another issue raised by Julien during review (the usage of p2m_ram_t).
> Amit, if you would like to give it a try I have a work-in-progress
> branch with the fixes here:

We did try new branch with new fixes but we see some other crash now.

XEN) Loading kernel from boot module @ 7a00
(XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
(XEN) No bank has been allocated below 4GB.
(XEN) BANK[0] 0x05-0x054000 (1024MB)
(XEN) BANK[1] 0x06-0x064000 (1024MB)
(XEN) Grant table range: 0x073fe0-0x073fe4
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 7a00 to 00050008-00050188
(XEN) Loading dom0 DTB to 0x00050800-0x0005080117d0
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing free RAM on in background
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 292kB init memory.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Boot CPU: AArch64 Processor [411fd073]
[0.00] Machine model: Renesas H3ULCB board based on r8a7795 ES2.0+
[0.00] earlycon: xenboot0 at I/O port 0x0 (options '')
[0.00] bootconsole [xenboot0] enabled
[0.00] Xen 4.12 support found
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] Reserved memory: created CMA memory pool at
0x5700, size 400 MiB
[0.00] OF: reserved mem: initialized node linux,cma@5700,
compatible id shared-dma-pool
[0.00] Reserved memory: created CMA memory pool at
0x7000, size 256 MiB
[0.00] OF: reserved mem: initialized node
linux,multimedia@7000, compatible id shared-dma-pool
[0.00] cma: dma_contiguous_reserve(limit 1)
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem
0x-0x00063fff]
[0.00] NUMA: NODE_DATA [mem 0x63ff90c00-0x63ff926ff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x5700-0x]
[0.00]   Normal   [mem 0x0001-0x00063fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x5700-0x7fff]
[0.00]   node   0: [mem 0x0005-0x00053fff]
[0.00]   node   0: [mem 0x0006-0x00063fff]
[0.00] Initmem setup node 0 [mem 0x5700-0x00063fff]
[0.00] On node 0 totalpages: 692224
[0.00]   DMA zone: 2624 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 167936 pages, LIFO batch:31
[0.00]   Normal zone: 8192 pages used for memmap
[0.00]   Normal zone: 524288 pages, LIFO batch:31
[0.00] bootmem alloc of 64 bytes failed!
[0.00] Kernel panic - not syncing: Out of memory
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
4.14.75-ltsi-yocto-standard #3
[0.00] Hardware name: Renesas H3ULCB board based on r8a7795 ES2.0+ (DT)
[0.00] Call trace:
[0.00] [] dump_backtrace+0x0/0x3c0
[0.00] [] show_stack+0x14/0x20
[0.00] [] dump_stack+0x9c/0xbc
[0.00] [] panic+0x11c/0x28c
[0.00] [] free_bootmem_late+0x0/0x7c
[0.00] [] __alloc_bootmem_low+0x2c/0x38
[0.00] [] setup_arch+0x258/0x4d8
[0.00] [] start_kernel+0x64/0x3ac
[0.00] ---[ end Kernel panic - not syncing: Out of memory

Thanks
-Amit

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

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

[Amit Tomer]

Hi,

> Not really, the DT provided by Amit is for the host. The memory node
> will be rewritten by Xen for Dom0  and does not include the
> reserved-memory regions so far.
>
Thanks for pointing that out.

Is it like we need to create "separate" reserve-memory
node(make_reserved-memory_node) when
memory node is encountered?

Thanks
-Amit

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

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

[Amit Tomer]

Hi,
> Looking at the stack trace, this is very likely due to the issue I pointed 
> out earlier on. I.e reserved-memory region should be described in the memory 
> nodes.

Do you mean, something like this(reserved-memory node is under memory node) ?

--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -17,23 +17,10 @@
memory@4800 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
-   reg = <0x0 0x4800 0x0 0x3800>;
-   };
-
-   memory@5 {
-   device_type = "memory";
-   reg = <0x5 0x 0x0 0x4000>;
-   };
-
-   memory@6 {
-   device_type = "memory";
-   reg = <0x6 0x 0x0 0x4000>;
-   };
-
-   memory@7 {
-   device_type = "memory";
-   reg = <0x7 0x 0x0 0x4000>;
-   };
+  reg = <0x0 0x4800 0x0 0x3800>,
+<0x5 0x 0x0 0x4000>,
+<0x6 0x 0x0 0x4000>,
+<0x7 0x 0x0 0x4000>;

reserved-memory {
#address-cells = <2>;
@@ -61,6 +48,7 @@
reg = <0x 0x7000 0x0 0x1000>;
};
};
+   };

Thanks
-Amit

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

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

[Amit Tomer]

Hi
> Thanks for testing! You might have found a real bug in the series. Could
> you please also attach the full device tree?

Please find the attached DTS and DTB file used for testing.

Thanks
-Amit


r8a7795-h3ulcb.dts
Description: audio/vnd.dts


r8a7795-h3ulcb.dtb
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,
> Have you tried to enable early_prink?

Yes, this is how we compiled it.

make dist-xen XEN_TARGET_ARCH=arm64 debug=y
CROSS_COMPILE=aarch64-linux-gnu-
CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000 -j16

> AFAIR, I tested that branch (ipmmu_v2) before submitting RFC patch
> series [1] and it was functional.
>
> But, I don't quite remember what the BSP version (U-Boot/ARM-TF) I had
> based on.

Ok.

Thanks
-Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> The proper command is:
>
> mkimage -A arm64 -C none -T kernel -a 0x7808 -e 0x7808 -n "XEN"
> -d xen/xen xen-uImage

Yeah but it didn't boot it up :(

[   16.991035] => setenv ipaddr 10.105.2.28;setenv serverip
10.105.2.27;ping 10.105.2.27
[   18.791456] ravb Waiting for PHY auto negotiation to complete... done
[   21.506184] ravb: 1000Base/Full
[   21.514787] Using ravb device
[   26.518321] host 10.105.2.27 is alive
[   26.522064] => tftp 0x4808 xen-uImage
[   32.859274] ravb:0 is connected to ravb.  Reconnecting to ravb
[   32.866626] ravb Waiting for PHY auto negotiation to complete... done
[   35.936229] ravb: 1000Base/Full
[   35.944824] Using ravb device
[   35.947840] TFTP from server 10.105.2.27; our IP address is 10.105.2.28
[   35.954733] Filename 'xen-uImage'.
[   35.958271] Load address: 0x4808
[   35.961990] Loading:
#
[   41.049127]
#
[   41.131627]   ##
[   41.154635]   141.6 KiB/s
[   41.157357] done
[   41.159264] Bytes transferred = 754064 (b8190 hex)
[   41.164605] => bootm 0x4808
[   48.511339] ## Booting kernel from Legacy Image at 4808 ...
[   48.517501]Image Name:   XEN
[   48.520855]Image Type:   AArch64 Linux Kernel Image (uncompressed)
[   48.527659]Data Size:754000 Bytes = 736.3 KiB
[   48.532921]Load Address: 4808
[   48.536731]Entry Point:  4808
[   48.540541]Verifying Checksum ... OK
[   48.548190]Loading Kernel Image ... OK
[   48.554182]
[   48.555635] Starting kernel ...
[   48.558901]

We even tried loading it to 0x7808.

Thanks
-Amit

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

Re: [Xen-devel] [PATCH 0/6] iomem cacheability

[Amit Tomer]

Hi,

> This series introduces a cacheability parameter for the iomem option, so
> that we can map an iomem region into a guest as cacheable memory.
>
> Then, this series fixes the way Xen handles reserved memory regions on
> ARM: they should be mapped as normal memory, instead today they are
> treated as device memory.
>

We tried testing this patch series on R-CAR platform but see following crash
when booting dom0 Linux.

[0.57] bd20:  08b27fa0
 08b27000
[0.585639] bd40: 0804bd50 08959164
[0.590565] [] cma_init_reserved_areas+0x98/0x1d0
[0.596876] [] do_one_initcall+0x38/0x120
[0.602493] [] kernel_init_freeable+0x188/0x228
[0.608628] [] kernel_init+0x10/0x100
[0.613898] [] ret_from_fork+0x10/0x18
[0.619250] ---[ end trace c2041e247871a6ff ]---
[0.623929] Unable to handle kernel paging request at virtual
address 7dffe55c
[0.631880] Mem abort info:
[0.634715]   Exception class = DABT (current EL), IL = 32 bits
[0.640684]   SET = 0, FnV = 0
[0.643786]   EA = 0, S1PTW = 0
[0.646990] Data abort info:
[0.649920]   ISV = 0, ISS = 0x0006
[0.653821]   CM = 0, WnR = 0
[0.656834] swapper pgtable: 4k pages, 48-bit VAs, pgd = 08b47000
[0.663670] [7dffe55c] *pgd=000700aef803,
*pud=000700af0803, *pmd=
[0.672652] Internal error: Oops: 9606 [#1] PREEMPT SMP
[0.678259] Modules linked in:
[0.681371] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
4.14.50-yocto-standard #1
[0.689923] Hardware name: Renesas Salvator-X board based on
r8a7795 ES2.0+ (DT)
[0.697355] task: 80001e91 task.stack: 08048000
[0.703317] PC is at cma_init_reserved_areas+0xbc/0x1d0
[0.708587] LR is at cma_init_reserved_areas+0x94/0x1d0
[0.713862] pc : [] lr : []
pstate: 6045
[0.721287] sp : 0804bd50
[0.724657] x29: 0804bd50 x28: 08a88a28
[0.730013] x27: 00057000 x26: 08994040
[0.735370] x25: 08b27fa0 x24: 08b27000
[0.740727] x23: 7e00 x22: 088ed000
[0.746084] x21:  x20: 
[0.751440] x19: 0004 x18: 
[0.756797] x17: 0001 x16: deadbeef
[0.762154] x15:  x14: 0400
[0.767511] x13: 0400 x12: 
[0.772872] x11:  x10: 0002
[0.778224] x9 :  x8 : 80001e945800
[0.783586] x7 :  x6 : 08b24868
[0.788938] x5 : 08b24868 x4 : 
[0.794295] x3 : 0780 x2 : 0007
[0.799652] x1 : 08a88a28 x0 : e55c
[0.805010] Process swapper/0 (pid: 1, stack limit = 0x08048000)
[0.811747] Call trace:
[0.814254] Exception stack(0x0804bc10 to 0x0804bd50)
[0.820734] bc00:
e55c 08a88a28
[0.828598] bc20: 0007 0780
 08b24868
[0.836460] bc40: 08b24868 
80001e945800 
[0.844322] bc60: 0002 
 0400
[0.852184] bc80: 0400 
deadbeef 0001
[0.860047] bca0:  0004
 
[0.867910] bcc0: 088ed000 7e00
08b27000 08b27fa0
[0.875772] bce0: 08994040 00057000
08a88a28 0804bd50
[0.883639] bd00: 08959160 0804bd50
08959188 6045
[0.891497] bd20:  08b27fa0
 08b27000
[0.899359] bd40: 0804bd50 08959188
[0.904285] [] cma_init_reserved_areas+0xbc/0x1d0
[0.910592] [] do_one_initcall+0x38/0x120
[0.916209] [] kernel_init_freeable+0x188/0x228
[0.922343] [] kernel_init+0x10/0x100
[0.927613] [] ret_from_fork+0x10/0x18
[0.932975] Code: f94262c0 aa0103fc cb803360 d37ae400 (f8776800)
[0.939104] ---[ end trace c2041e247871a700 ]---
[0.943800] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.943800]
[0.953021] SMP: stopping secondary CPUs
[0.957009] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b

Below is how reserved node looks like:

 reserved-memory {
 #address-cells = <2>;
 #size-cells = <2>;
 ranges;

 /* device specific region for Lossy Decompression */
 lossy_decompress: linux,lossy_decompress@5400 {
 no-map;
 reg = <0x 0x5400 0x0 0x0300>;
 };

 /* For Audio DSP */
 

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hello,

> > Did removing reserved-memory regions together with users work out well
> > for you?

Removing "reserved-memory" node along with "mmngr" worked well. Tested it
with v3.15 BSP release.

Also, just tried loading XEN from one of your branch[1] but it stuck with this:

[   13.793305] host 10.105.2.27 is alive
[   13.797050] => tftp 0x4800 xen
[   20.944681] ravb:0 is connected to ravb.  Reconnecting to ravb
[   20.952032] ravb Waiting for PHY auto negotiation to complete... done
[   23.964201] ravb: 1000Base/Full
[   23.972794] Using ravb device
[   23.975792] TFTP from server 10.105.2.27; our IP address is 10.105.2.28
[   23.982685] Filename 'xen'.
[   23.985588] Load address: 0x4800
[   23.989307] Loading:
#
[   29.073520]
#
[   29.155589]   ##
[   29.178818]   141.6 KiB/s
[   29.181540] done
[   29.183447] Bytes transferred = 754000 (b8150 hex)
[   29.188789] => booti 0x4800
[   34.990295] Image lacks image_size field, assuming 16MiB
[   34.995837]
[   34.997362] Starting kernel ...
[   35.000628]

Do we need to chose some other address where it should be loaded ?

[1]: https://github.com/otyshchenko1/xen/tree/ipmmu_v2

Thanks
 -Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hello,

> Did removing reserved-memory regions together with users work out well
> for you?

Sorry, didn't get chance to work on this today. I would test it and
let you know.

Thanks
-Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> (1) 
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1
>
> (2) 
> https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts

Yeah, this is what I thought initially but was not able to compile dts
file after removing the reserve node.

Will try it again, Thanks for pointing it out.

Thanks
-Amit.

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d9836779d1..08b9cd2c44 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
>  printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>
> +dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
> +
>  left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
> kinfo->fdt,
> fdt_totalsize(kinfo->fdt));
>
Please find the logs after applying this patch:

(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading Domd0 kernel from boot module @ 7a00
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x005000-0x007000 (512MB)
(XEN) Grant table range: 0x004800-0x004804
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 7a00 to 5008-5188
(XEN) Loading dom0 DTB to 0x5800-0x58010a44
(XEN) dom0 IPA 0x5800
(XEN) P2M @ 00080c23dc90 mfn:0x73ff5e
(XEN) 0TH[0x0] = 0x00873ff5c7ff
(XEN) 1ST[0x1] = 0x00873ff3d7ff
(XEN) 2ND[0xc0] = 0x02c0580006fd
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Unable to copy the DTB to dom0 memory (left = 68164 bytes)
(XEN) 
(XEN)
(XEN) Reboot in five seconds...

Thanks
-Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> We use earlier BSP version and we didn't face the similar issue.
>
> We have a plan to switch to recent BSP version (3.15). So, I will come
> up with updates when we migrate.

Thanks for this information, we have now built it for 3.9 but yet to
test the images.
Also, it would be great if you can let us know the XEN version you use with BSP
images?

Thanks,
-Amit.

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi

> [1]  https://elinux.org/R-Car/Boards/Yocto-Gen3

 We tried BSP release v3.15.0 from above link but see following message:

[   45.518865] => setenv xen_addr_r 0x4800;setenv fdt_addr_r
0x4a00;setenv kernel_addr_r 0x7a00
[   52.430467] => setenv fdt_high 0x;fdt addr $fdt_addr_r;fdt resize
[   55.348938] => setenv xen_bootargs console=dtuart dom0_mem=512M
[   57.661868] => setenv dom0_bootargs console=hvc0,115200n8
earlycon=xenboot debug clk_ignore_unused root=/dev/mmcblk1 rw rootwait
[   59.813185] => fdt set /chosen xen,xen-bootargs \"$xen_bootargs\";
[   62.037351] => fdt set /chosen xen,dom0-bootargs
\"$dom0_bootargs\";fdt mknode /chosen modules
[   65.765571] => fdt set /chosen/modules '#address-cells' <1>;fdt set
/chosen/modules '#size-cells' <1>;fdt mknode /chosen/modules module@0
[   68.086099] => fdt set /chosen/modules/module@0 compatible
"xen,linux-zimage" "xen,multiboot-module"
[   70.205113] => fdt set /chosen/modules/module@0 reg <
$kernel_addr_r 0x180 >
[   72.165412] => booti ${xen_addr_r} - ${fdt_addr_r}
[   74.021004] ## Flattened Device Tree blob at 4a00
[   74.026244]Booting using the fdt blob at 0x4a00
[   74.031691]reserving fdt memory region: addr=4800 size=4
[   74.038310]reserving fdt memory region: addr=4a00 size=12000
[   74.044936]Loading Device Tree to 7d71, end
7d724fff ... OK
[   74.054036]
[   74.055489] Starting kernel ...
[   74.058755]
- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4800 - 7fff
(XEN) RAM: 0005 - 00053fff
(XEN) RAM: 0006 - 00063fff
(XEN) RAM: 0007 - 00073fff
(XEN)
(XEN) MODULE[0]: 7d71 - 7d722000 Device Tree
(XEN) MODULE[1]: 7a00 - 7b80 Kernel
(XEN)  RESVD[0]: 4800 - 4804
(XEN)  RESVD[1]: 4a00 - 4a012000
(XEN)  RESVD[2]: 7d71 - 7d722000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=512M
(XEN) PFN compression on bits 19...19
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "serial0", options "115200n8"
(XEN) WARNING: UART configuration is not supported
 Xen 4.12.0-rc
(XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y  Wed Feb  6
16:23:25 I9
(XEN) Latest ChangeSet: Thu Jan 24 14:03:48 2019 + git:755eb64
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(XEN) 64-bit Execution:
(XEN)   Processor Features:  
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1124 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.1
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f101
(XEN) gic_cpu_addr=f102
(XEN) gic_hyp_addr=f104
(XEN) gic_vcpu_addr=f106
(XEN) gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at 

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,
> I am wondering what Android version you are using. What is your use-case?

We are trying with Android O 8.1 version.

> This is our development product
> https://github.com/xen-troops/meta-xt-prod-devel
> which in addition to Linux guest contains Android P guest.
>
After making some changes in domU bootargs, we can now see
console service trying to start but goes into loop with message:

[6.432864] init: starting service 'console'...
[6.433974] init: property_set("ro.boottime.console", "6432469848")
failed: property already set
[6.434580] init: setpgid failed for console: Operation not permitted
[6.434743] init: cannot setexeccon('u:r:shell:s0') for console:
Permission denied
[6.435434] init: Service 'console' (pid 781) killed by signal 6
[6.435483] init: Sending signal 9 to service 'console' (pid 781)
process group...
[6.435608] init: Successfully killed process cgroup uid 2000 pid 781 in 0ms

Also, one other query. In order to get graphics and audio up in dom0
kernel, do we
need to load special/proprietary graphics/audio driver with mainline kernel
and Ubuntu Debian rootfs on H3 platform?

Thanks
-Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]

Thanks , this worked for us and we can now boot Linux guest in domU.

But now, while booting Android as domU guest , we don't get console
login for domU and it stuck
here:

[   10.597394] usbcore: registered new interface driver cdc_acm
[   10.597436] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[   10.599829] file system registered
[   10.611942] kauditd_printk_skb: 6 callbacks suppressed
[   10.611947] audit: type=1400 audit(1550239280.843:17): avc:  denied
 { entrypoint } for  pid=864 comm="init" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.616842] audit: type=1400 audit(1550239280.847:18): avc:  denied
 { map } for  pid=864 comm="adbd" path="/system/bin/adbd" dev="xvda1"
ino=889 scontext=u:r:adbd:s0 tcontext=u:object_r:unlabeled:s0
tclass=file permissive=1
[   10.617012] audit: type=1400 audit(1550239280.851:19): avc:  denied
 { read execute } for  pid=864 comm="adbd" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   10.747628] random: adbd: uninitialized urandom read (40 bytes read)

Is there a special way to give hvc console login in Android , the way
we do it in Ubuntu is to create hvc0.conf file?

Thanks
- Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,

> Would try changes mentioned by you.

We managed to boot XEN with dom0 kernel on H3.

But we see following , when we try to domU guest:

# xl create -c config.xl
Parsing config from config.xl
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/block add [2417] exited with error status 1
libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb:
script: File /home/amit_new/guest_domU/rootfs.img is read-only, and so
I willt
mount it read-write in a guest domain.
libxl: error: libxl_create.c:1318:domcreate_launch_dm: Domain 1:unable
to add disk devices
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/block remove [2461] exited with error status 1
libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb:
script: /etc/xen/scripts/block failed; error detected.
(XEN) mm.c:1401:d0v0 gnttab_mark_dirty not implemented yet
libxl: error: libxl_domain.c:1038:libxl__destroy_domid: Domain
1:Non-existant domain
libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain
1:Unable to destroy guest
libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain
1:Destruction of domain failed

where #cat config.xl
name = "guest-1"
kernel = "Image"
extra = "root=/dev/xvda rw xencons=tty console=hvc0"
memory = 256
vcpus = 1
disk = [ 'rootfs.img,raw,xvda,rw' ]

Any idea what is going wrong here ?

-Thanks,
Amit

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

Re: [Xen-devel] XEN on R-CAR H3

[Amit Tomer]

Hi,Thanks for prompt reply.

> Memory nodes got duplicated somehow. Likely U-Boot did something incorrect.
>
> Try to use single memory node in your device-tree instead of separated
> by each bank nodes:
>
> memory@4800 {
>  device_type = "memory";
>  /* first 128MB is reserved for secure area. */
>  reg = <0x0 0x4800 0x0 0x3800>,
><0x5 0x 0x0 0x4000>,
><0x6 0x 0x0 0x4000>,
><0x7 0x 0x0 0x4000>;
> };
>
> --
Sorry, I should have read the other thread completely where Andrii
Anisov has suggested the same.
Would try changes mentioned by you.

Thanks
-Amit

> Regards,
>
> Oleksandr Tyshchenko
>

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

[Xen-devel] XEN on R-CAR H3

[Amit Tomer]

HI,

Trying to boot XEN on R-CAR H3 starter Kit board.

Linux image based on 5.0.0-rc5 and XEN image is 4.12

tftp 0x4800 xen;tftp 0x7a00 Image; tftp 4a00 r8a7795-h3ulcb.dtb
setenv xen_addr_r 0x4800
setenv fdt_addr_r 4a00
setenv kernel_addr_r 0x7a00
fdt addr $fdt_addr_r
fdt resize
fdt set /chosen xen,xen-bootargs "console=dtuart dom0_mem=384M"
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt mknod /chosen module@0
fdt resize
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <$kernel_addr_r 0x180>
setenv bootargs "console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused
rootwait earlycon=xenboot"

But when It boot it, I see following crash:


booti 0x4800 - 0x4a00
## Flattened Device Tree blob at 4a00
 Booting using the fdt blob at 0x4a00
reserving fdt memory region: addr=4a00 size=1
Using Device Tree in place at 4a00, end
4a012fff

 Starting kernel ...
 UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4800 - 7fff
(XEN) RAM: 0005 - 00053fff
(XEN) RAM: 0006 - 00063fff
(XEN) RAM: 0007 - 00073fff
(XEN) RAM: 0005 - 00053fff
(XEN) RAM: 0006 - 00063fff
(XEN) RAM: 0007 - 00073fff
(XEN)
(XEN) MODULE[0]: 4a00 - 4a01 Device Tree
(XEN) MODULE[1]: 7a00 - 7b80 Kernel
(XEN)  RESVD[0]: 4a00 - 4a01
(XEN)
(XEN)
(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=384M
(XEN) PFN compression on bits 19...19
(XEN) Xen BUG at page_alloc.c:274
(XEN) [ Xen-4.12.0-rc  arm64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 0028b30c page_alloc.c#bootmem_region_add+0x184/0x194
(XEN) LR: 0028b36c
(XEN) SP: 002d7d00
(XEN) CPSR:   83c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 0050  X1: 0003  X2: 0006
(XEN)  X3: 0054  X4: 88121000  X5: 0028
(XEN)  X6: 0060  X7: 0004  X8: 0001
(XEN)  X9: 000a X10: 002d7afa X11: 0031
(XEN) X12: 0002 X13: 0026e5e8 X14: 0020
(XEN) X15: 0040 X16:  X17: 
(XEN) X18: 7d726e08 X19: 0050 X20: 0054
(XEN) X21: 00054000 X22: 0005 X23: 00054000
(XEN) X24: 0028b31c X25: 002b8400 X26: 4800
(XEN) X27: 00074000 X28: 0004  FP: 002d7d00
(XEN)
(XEN)   VTCR_EL2: 8000
(XEN)  VTTBR_EL2: 
(XEN)
(XEN)  SCTLR_EL2: 30cd183d
(XEN)HCR_EL2: 0038
(XEN)  TTBR0_EL2: 48114000
(XEN)
(XEN)ESR_EL2: f201
(XEN)  HPFAR_EL2: 
(XEN)FAR_EL2: 
(XEN)
(XEN) Xen stack trace from sp=002d7d00:
(XEN)002d7d40 0028b36c 0001 0005
(XEN)00054000 0005 00054000 002d7d90
(XEN)002d7d90 0029c8f8 0001 0005
(XEN)00054000 0005 00054000 0001
(XEN)002e 0005 002d7de0 0029dac0
(XEN)00054000 0005 00054000 002b83c0
(XEN) 002b83d8 4a00 4a01
(XEN)7d726a90 00200608 4800 47e0
(XEN)4a00  0040 
(XEN)0001   
(XEN) 0001 4a00 00013800
(XEN)002b83c0 0028b31c  
(XEN) 0003  0440
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   

Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support

[Amit Tomer]

Hi,

Thanks for having a detailed look at it.

> > +#define UART_STATUS_REG 0x0c
> > +#define UART_TX_REG 0x00
>> Why ldrh? This is a 32-bit register, actually you can't be sure that the
> device supports a 16-bit access. Besides: the bit you are after is in
> the upper half, so you actually will never see the bit set. I wonder if
> you are loosing characters here.

Let me confess with ldrh, I do see output scattered all over the screen and
really wondering why the hell I didn't notice it when I sent this RFC.

Very sorry about that.

> > +.macro early_uart_transmit xb wt
> > + strb  \wt, [\xb, #UART_TX_REG]
>
> TX_WFIFO is a 32-bit register, so you should rather use a 32-bit
> accessor.

Ok.I guess "str" would be OK to use ?

Thanks
-Amit.

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

Re: [Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC

[Amit Tomer]

Hello,

> >>> +reg = meson_s905_read(uart, UART_CONTROL);
> >>> +reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR);
> >>
> >>
> >> I am not sure why you are clearing those bits. AFAIU, init_preirq will 
> >> reset
> >> the serials, so you want to set thoses bits. This seems to be confirmed by
> >> Linux in meson_uart_reset.
> >
> > Idea here is to set these bits to their default values(which is 0 ) and if 
> > you
> > look at other drivers in XEN, it seems to be done same thing(clear
> > those bits) with them.
>
> Are you sure about this? RX_RST and TX_RST are bit to reset the
> transmission and receive path. Looking at a couple of different drivers
> (cache-uart.c and mvebu-uart.c), those 2 bits are set and I suspect be
> cleared by the hardware once reset.

It's bit confusing to me, eventually Linux driver seems to clear those bits

https://github.com/torvalds/linux/blob/master/drivers/tty/serial/meson_uart.c#L266

Thanks
-Amit

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

Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support

[Amit Tomer]

Hello,

> I am trying to understand why Linux is doing it. Do you expect all
> U-Boot version to do it?

It's because Linux doesn't really trust u-boot and initializes every
thing again ?
Mainline U-boot does it but that may also not required since ATF does it for us.

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v2] xen:arm: Populate arm64 image header

[Amit Tomer]

Hello,

Thanks for having a look.

On Wed, Sep 5, 2018 at 6:07 PM Andre Przywara  wrote:
>
> Hi,
>
> I don't think it's helpful to hide that KERNEL_SIZE definition in
> another file. Please just put "_end - start" here.

Yeah,  I thought about it and felt that it would be cleaner and more
readable if we use macros here.

Also, wanted to have minimal changes in head.S and that is the reason
for using assemble.h.

> Either you call this __HEAD_FLAG_PAGE_SIZE_4K, or, even better, copy the
> Linux definition, which would make it obvious where this comes from and
> would alert any developer of the PAGE_SIZE dependency.
>
> Plus move those into head.S, as mentioned above.

Ok.
> > +
> > +#define __KERNEL_SIZE   (_end - start)
> > +
> >  #endif /* __ASM_ASSEMBLER_H__ */
> >

Thanks
-Amit

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

Re: [Xen-devel] [PATCH] xen:arm: Populate arm64 image header

[Amit Tomer]

Hello,

> Yes, and in fact it seems one can work around this by cleverly
> constructing the load addresses,

But we are really dealing a corner case here. No matter where
we load the image, it would be relocated to 0x8( since dram
starts at 0x...) and unfortunately first 16MiB is reserved for
ROM Firmware.

> >> This unwanted situation can be fixed by updating image_size field
> >> along side kernel flags so that image wouldn't relocate from initial
> >> load address.
> >
> > I think the first step is to fix your U-boot and rethink where you load
> > your binaries.
>
> I think U-Boot perfectly complies with the kernel document. Xen not so
> much. The kernel image format was deliberately updated to become more
> flexible with certain memory layout situations as we have here.
> There is for instance a problem if there is something precious at 512KB
> into DRAM (secure memory owned by firmware), as regardless of the load
> addresses the user chooses U-Boot will (rightfully!) revert to the
> original "512KB into DRAM" address to keep compatibility with older
> kernels - and it believes Xen is such a one because of the ancient
> header format.
>
> But ...
>
> > Regarding the patch in itself, I think this is a good addition as it
> > allow Xen to be loaded in more places. But please rewrite the commit
> > message accordingly, this is an update to a new version.
>
> I totally agree with that, the commit message should be reworded to
> stress that we want to comply with a newer version of the kernel image
> header (which is around for four years by now!), and just mention that
> it fixes problems with non-ancient U-Boots on certain platforms as an
> additional reason.
>
> >> [1]:https://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/lib/image.c;h=699bf44e702f7a7084997406203fd7d2aaaf87fa;hb=HEAD#l50
> >>
> >>
> >> These changes are derived from kernel v4.18 files
> >>
> >> Signed-off-by: Amit Singh Tomar 
> >> ---
> >>   xen/arch/arm/arm64/head.S |  5 ++-
> >>   xen/arch/arm/arm64/lib/assembler.h| 11 +
> >>   xen/arch/arm/xen.lds.S|  3 ++
> >>   xen/include/asm-arm/arm64/linux_header_vars.h | 62
> >> +++
> >>   4 files changed, 79 insertions(+), 2 deletions(-)
> >>   create mode 100644 xen/include/asm-arm/arm64/linux_header_vars.h
> >>
> >> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> >> index d63734f..ce72c95 100644
> >> --- a/xen/arch/arm/arm64/head.S
> >> +++ b/xen/arch/arm/arm64/head.S
> >> @@ -25,6 +25,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include "lib/assembler.h"
> >> #define PT_PT 0xf7f /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=1
> >> P=1 */
> >>   #define PT_MEM0xf7d /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=0
> >> P=1 */
> >> @@ -120,8 +121,8 @@ efi_head:
> >>   add x13, x18, #0x16
> >>   b   real_start   /* branch to kernel start */
> >>   .quad   0/* Image load offset from start
> >> of RAM */
> >> -.quad   0/* reserved */
> >> -.quad   0/* reserved */
> >> +le64sym _kernel_size_le  /* Effective size of kernel
> >> image, little-endian */
> >> +le64sym _kernel_flags_le /* Informative flags,
> >> little-endian */
> >
> > All the dance for to convert to little endian is not necessary on Xen.
> > Please rework your series to avoid such code, this would also reduce
> > quite significantly the series.
>
> Indeed!

How about this change?

index ce72c95..ec29e01 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -121,8 +121,8 @@ efi_head:
 add x13, x18, #0x16
 b   real_start   /* branch to kernel start */
 .quad   0/* Image load offset from start of RAM */
-le64sym _kernel_size_le  /* Effective size of kernel
image, little-endian */
-le64sym _kernel_flags_le /* Informative flags, little-endian */
+.quad   _end - start  /* Effective size of kernel image,
little-endian */
+.quad   __HEAD_FLAGS /* Informative flags, little-endian */
 .quad   0/* reserved */
 .quad   0/* reserved */
 .quad   0/* reserved */
diff --git a/xen/arch/arm/arm64/lib/assembler.h
b/xen/arch/arm/arm64/lib/assembler.h
index c0ef758..05861b8 100644
--- a/xen/arch/arm/arm64/lib/assembler.h
+++ b/xen/arch/arm/arm64/lib/assembler.h
@@ -9,15 +9,11 @@
 #define CPU_BE(x...)
 #define CPU_LE(x...) x

-/*
- * Emit a 64-bit absolute little endian symbol reference in a way that
- * ensures that it will be resolved at build time, even when building a
- * PIE binary. This requires cooperation from the linker script, which
- * must emit the lo32/hi32 halves individually.
- */
-.macro  le64sym, sym
-.long   \sym\()_lo32
-.long  

Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support

[Amit Tomer]

Hello,

> I would prefer if no new alias are added. The same could be achieved with
> CONFIG_EARLY_PRINTK=meson,0xc81004c0.
>
> This could be documented on the wiki.

Ok.

> I would prefer if we stick with the spec name. So UART_TX_REG should be
> renamed UART_WFIFO_REG.

Yeah right, got your point.
>
> Also, it might be worth considering to prefix them with AML_ so it is easy
> to find them on lookup.

Initially used AML_ as prefix but then I just wanted to be consistent it with
other uart drivers in XEN.

> Looking at the earlyconsole implementation in Linux, it seems that TX needs
> to be enabled first (see meson_uart_enable_tx_engine).
>
> Is it now done in the firmware?

Yes, this has been done in u-boot.
shouldn't we trust it?


>> + */
>> +.macro early_uart_ready xb c
>> +1:
>> +ldrh   w\c, [\xb, #UART_STATUS_REG] /* status register */
>> +tstw\c, #(1 << 21)  /* Check TXFIFO FULL bit */
>
>
> Please define 1 << 21 rather than hardcoding it.

Ok.


Thanks
-Amit

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

Re: [Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC

[Amit Tomer]

Hello,

Thanks for having a look at it.

> The spec does not seems to provide the offset register. Where did you find
> them?

Actually, looked at couple of references from u-boot and Linux. These
headers are picked from there.

> AFAIK, {0} is not necessary.

Ok.

>> +
>> +#define meson_s905_read(uart, off)   readl((uart)->regs + off)
>> +#define meson_s905_write(uart, off, val) writel(val, (uart->regs) +
>> off)
>
>
> s/(uart->regs)/(uart)->regs/
>
>> +
>> +static void meson_s905_uart_interrupt(int irq, void *data,
>> +struct cpu_user_regs *regs)
>
>
> The indentation looks wrong here.
>
>> +{
>> +struct serial_port *port = data;
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t st = meson_s905_read(uart, UART_STATUS);
>> +
>> +if ( !(st & UART_RX_EMPTY) )
>> +{
>> +serial_rx_interrupt(port, regs);
>> +}
>> +
>> +if ( !(st & UART_TX_FULL) )
>> +{
>> +if ( st & UART_TX_INT_EN )
>> +serial_tx_interrupt(port, regs);
>> +}
>> +
>
>
> NIT: No need for this newline.
>
>> +}
>> +
>> +static void __init meson_s905_uart_init_preirq(struct serial_port *port)
>> +{
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t reg;
>> +
>> +reg = meson_s905_read(uart, UART_CONTROL);
>> +reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR);
>
>
> I am not sure why you are clearing those bits. AFAIU, init_preirq will reset
> the serials, so you want to set thoses bits. This seems to be confirmed by
> Linux in meson_uart_reset.

Idea here is to set these bits to their default values(which is 0 ) and if you
look at other drivers in XEN, it seems to be done same thing(clear
those bits) with them.

>
>> +reg = meson_s905_read(uart, UART_CONTROL);
>> +reg &= ~(UART_RX_INT_EN | UART_TX_INT_EN);
>> +meson_s905_write(uart, UART_CONTROL, reg);
>> +}
>> +
>> +static void __init meson_s905_uart_init_postirq(struct serial_port *port)
>> +{
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t reg;
>> +
>> +uart->irqaction.handler = meson_s905_uart_interrupt;
>> +uart->irqaction.name= "meson_s905_uart";
>> +uart->irqaction.dev_id  = port;
>> +
>> +if ( setup_irq(uart->irq, 0, >irqaction) != 0 )
>> +{
>> +printk("Failed to allocated meson_s905_uart IRQ %d\n",
>> uart->irq);
>> +return;
>> +}
>> +
>> +/* Configure Rx/Tx interrupts based on bytes in FIFO */
>> +reg = meson_s905_read(uart, UART_MISC);
>
>
> You read UART_MISC here but ...
>
>> +reg = (UART_RECV_IRQ_CNT_MASK & 1) |
>
>
> ... override the value here. You either want to drop reading UART_MISC or
> add | here.

Sorry, missed "|" somehow.
>
>> +   (UART_XMIT_IRQ_CNT_MASK & ((TX_FIFO_SIZE / 2) << 8));
>
>
> This is a bit difficult to read. It feels like you want to use a macro with
> a parameter that will do the correct masking.

Ok, shall I take it from Linux ?

>> +
>> +static const struct dt_device_match meson_dt_match[] __initconst =
>> +{
>> +DT_MATCH_COMPATIBLE("amlogic,meson-uart"),
>
>
> Looking at Linux, this is considered as a legacy bindings. Would not it be
> better to use stable bindings in Xen?
>

Yeah, I took it from u-boot source and didn't realize that there are
stable binding exists.

Thanks
-Amit

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

Re: [Xen-devel] [cubieboard2] Bringing up dom0

[Amit Tomer]

Hello
>
> debian@debian-armhf:~$ sudo xl list
> NameID   Mem VCPUsState
> Time(s)
>
>
> Now what am I missing?

You may need to run following

# /etc/init.d/xencommons start

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v3 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[Amit Tomer]

Hi,

> Compiled with CONFIG_EARLY_PRINTK=mvebu, I see Xen's pre-DT boot
> messages. In addition to my Reviewed-by:
>
> Tested-by: Andre Przywara 
>

Thank you!

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Tomer]

Hi,

> Works like a charm, can log into Dom0, Xen console works as well. So in
> addition to my Reviewed-by:
>
> Tested-by: Andre Przywara 
>

 Thank you for your time on this!

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Tomer]

Hi,

> Ah yes, if that works, we should. That bit is from the Linux BSP, isn't it?

Yes, it's from Linux BSP code only. Hope following is fine.

if ( reg & STATUS_TXFIFO_EMP )
return TX_FIFO_SIZE;
else if ( reg & STAT_TX_FIFO_HFL )
return TX_FIFO_SIZE / 2;
else if ( !(reg & STAT_TX_FIFO_FUL) )
return 1;

   return 0;

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Tomer]

Hi,

> Just a nit, but it might be smarter to first check for the receive IRQ,
> because not handling this might loose information. TX is less critical.

Ok, actually tried it ealier when  I was debugging the Rx path issue and
that time it didn't work. May be I should try it again.


> Similar to the earlyprintk behaviour we are a bit pessimistic here. I
> don't know if there is a way to determine the number of free characters
> in the FIFO, but we could at least return 1 if the FIFO is not full:
>
> if (fifo_empty)
> return FIFO_SIZE;
> if (!fifo_full)
> return 1;
> return 0;

Yeah, I thought of it initially like should we also return half the
size of FIFO(16) when STAT_TX_FIFO_HFL bit is set ?


Thanks
-Amit.

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

Re: [Xen-devel] [PATCH v1] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Amit Tomer]

Hello,

> I tested this on my board and it works like expected. I would very much
> like to see this driver still in 4.11.

Thanks for looking into it and Many Thanks for testing it out.

>
> Some (minor) comments on the code below.
>
> On 16/03/18 17:34, Amit Singh Tomar wrote:
>> This patch adds driver for UART controller found on Armada 3700 SoC.
>
> Can you please mention "Marvell" in the subject?

Ok.

> These should be indented by one tab (plus two spaces for the help text).
> It's not obvious - I got this wrong myself the other day ;-), but it's
> how the rest of the file works.

Ok.

> No need for the brackets.

Ok.

> Indentation.

Ok.

> So why do we need this include file, in a shared directory?
> All those bits are private to the UART driver and don't need to be
> exposed to Xen at all.
> If it's about the earlyprintk support: that's just two values needed
> there, nothing worth a new include file, I think.
> So I would recommend to declare the required constants directly in the
> driver file.

Yes, I thought earlyprintk could also use a couple of common defines and other
drivers do the same way.


Thanks
-Amit

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

Re: [Xen-devel] Xen support on arm64 platform

[Amit Tomer]

Hi,

On Wed, Mar 21, 2018 at 11:27 AM, Jayadev Kumaran  wrote:
> Hello all,
>
> I need to setup Xen on Snapdragon 820 platform - armv8 64 bit architecture.
> Is there support available for the same ? Is there Xen implementation on any
> other similar platform ?

From Initial investigation(I may be wrong), it looks like there is no
XEN port available for Snapdragon 820.

Specially , Snapdragon 820 uses the specific
uart(./drivers/tty/serial/msm_serial.c from Linux ?) that has not been
ported to XEN(Without it debugging would be difficult)

Thanks
-Amit

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

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Amit Tomer]

> earlycon=xenboot enables the early console for the hardware domain only.
> What I meant is having earlyprintk for Xen (see CONFIG_EARLY_PRINTK). This
> is used for low-level debug when booting the hypervisor.

Ok, Thanks. It's now clear to me.

Thanks
Amit

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

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Amit Tomer]

Hi,

> This is quite useful to get output without any serial driver. I am quite
> impressed you managed to debug your serial driver without it :).

Actually,  we have earlycon=xenboot(suggested by Andre) enabled in
Dom0 bootargs and it allowed us to
debug XEN boot further.

I am wondering if ealycon interface can be used in absence of
earlyprintk doing same work?

Thanks
Amit.

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

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Amit Tomer]

Hi

Thanks for the comments.

> OOI, do you have any plan for adding earlyprintk support for that platform?

I didn't think about it but I would look into it.

> Please give a link to the Linux driver. This would help me for reviewing and
> also for future reference.

Ok.

> This is part of xen/drivers/char/* so even if the driver if only for ARM
> hardware, you likely want to CC "THE REST" maintainers as this is under
> drivers/char. scripts/get_maintainers.pl can help you to find relevant
> maintainers to CC on each patch.

Ok.

  include should be first, then .

Ok, I was under the impression that it should be sorted in alphabetical order.

>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
>
> xen/serial.h is mentioned twice.
Ok.

>
>> +#include 
>> +
>> +#define UART_RX_REG 0x00
>> +#define RBR_BRK_DET BIT(15)
>> +#define RBR_FRM_ERR_DET BIT(14)
>> +#define RBR_PAR_ERR_DET BIT(13)
>> +#define RBR_OVR_ERR_DET BIT(12)
>> +
>> +#define UART_TX_REG 0x04
>> +
>> +#define UART_CTRL_REG   0x08
>> +#define CTRL_SOFT_RST   BIT(31)
>> +#define CTRL_TXFIFO_RST BIT(15)
>> +#define CTRL_RXFIFO_RST BIT(14)
>> +#define CTRL_ST_MIRR_EN BIT(13)
>> +#define CTRL_LPBK_ENBIT(12)
>> +#define CTRL_SND_BRK_SEQBIT(11)
>> +#define CTRL_PAR_EN BIT(10)
>> +#define CTRL_TWO_STOP   BIT(9)
>> +#define CTRL_TX_HFL_INT BIT(8)
>> +#define CTRL_RX_HFL_INT BIT(7)
>> +#define CTRL_TX_EMP_INT BIT(6)
>> +#define CTRL_TX_RDY_INT BIT(5)
>> +#define CTRL_RX_RDY_INT BIT(4)
>> +#define CTRL_BRK_DET_INTBIT(3)
>> +#define CTRL_FRM_ERR_INTBIT(2)
>> +#define CTRL_PAR_ERR_INTBIT(1)
>> +#define CTRL_OVR_ERR_INTBIT(0)
>> +#define CTRL_RX_INT (CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
>> + CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
>> +
>> +#define UART_STATUS_REG 0x0c
>> +#define STATUS_TXFIFO_EMP   BIT(13)
>> +#define STATUS_RXFIFO_EMP   BIT(12)
>> +#define STATUS_TXFIFO_FUL   BIT(11)
>> +#define STATUS_TXFIFO_HFL   BIT(10)
>> +#define STATUS_RX_TOGL  BIT(9)
>> +#define STATUS_RXFIFO_FUL   BIT(8)
>> +#define STATUS_RXFIFO_HFL   BIT(7)
>> +#define STATUS_TX_EMP   BIT(6)
>> +#define STATUS_TX_RDY   BIT(5)
>> +#define STATUS_RX_RDY   BIT(4)
>> +#define STATUS_BRK_DET  BIT(3)
>> +#define STATUS_FRM_ERR  BIT(2)
>> +#define STATUS_PAR_ERR  BIT(1)
>> +#define STATUS_OVR_ERR  BIT(0)
>> +#define STATUS_BRK_ERR  (STATUS_BRK_DET | STATUS_FRM_ERR | \
>> +STATUS_PAR_ERR | STATUS_OVR_ERR)
>> +
>> +#define UART_BAUD_REG   0x10
>> +#define UART_POSSR_REG  0x14
>
>
> Can you please only define only registers/bits used in the code?

Ok.

>> +
>> +#define TX_FIFO_SIZE32
>> +#define RX_FIFO_SIZE64
>> +
>> +static struct mvebu3700_uart {
>> +unsigned int baud, data_bits, parity, stop_bits;
>
>
> Are all those fields necessary? For instance, you always set baud but never
> read it.

Not sure about this as I don't know if these fields are used by XEN
serial infrastructure later on.

>> +unsigned int irq;
>> +void __iomem *regs;
>> +struct irqaction irqaction;
>> +struct vuart_info vuart;
>> +} mvebu3700_com = {0};
>> +
>> +#define PARITY_NONE  (0)
>> +
>> +#define mvebu3700_read(uart, off)   readl((uart)->regs + off)
>> +#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) +
>> off)
>> +
>> +static void mvebu3700_uart_interrupt(int irq, void *data, struct
>> +cpu_user_regs *regs)
>
>
> The indentation looks wrong here.
>
>> +{
>> +struct serial_port *port = data;
>> +struct mvebu3700_uart *uart = port->uart;
>> +unsigned int st = mvebu3700_read(uart, UART_STATUS_REG);
>> +
>> +if ( st & STATUS_TX_RDY )
>> +serial_tx_interrupt(port, regs);
>> +
>> +if ( st & (STATUS_RX_RDY | STATUS_OVR_ERR | STATUS_FRM_ERR |
>> STATUS_BRK_DET) )
>> +serial_rx_interrupt(port, regs);
>> +}
>> +
>> +static void __init mvebu3700_uart_init_preirq(struct serial_port *port)
>> +{
>> +struct mvebu3700_uart *uart = port->uart;
>> +unsigned ret;
>
>
> 'ret' is a bit confusion. I would expect to be the return value of the
> function but it is used a temporary variable for reading/write reg. You
> might want to rename to 'reg' for more clarity.
Ok.

> But as this is a register value (i.e specific size), please use uint32_t.
>
>> +
>> +ret = mvebu3700_read(uart, UART_CTRL_REG);
>> +ret |= (CTRL_TXFIFO_RST | CTRL_RXFIFO_RST);
>> +mvebu3700_write(uart, UART_CTRL_REG, ret);
>> +
>> +/* Before we make IRQ request, Clear the error bits of state register
>> */
>
>
> s/Clear/clear/ and missing full stop.

Ok.
>
>
>> +ret = 

Re: [Xen-devel] [RFC PATCH] xen/arm64: Add Support for Marvell ARMADA 3700 SoC

[Amit Tomer]

Hi,

Thanks for looking into.

> Would you mind creating a page on Xen wiki to explain how to boot Xen on
> that board? See [1].

Sure, I would do it and it was on my TODO list as well.

Thanks
Amit.

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

Re: [Xen-devel] [PATCH] ARM: GICv3: copy Dom0 GICv3 reg property from host DT

[Amit Tomer]

Hi,

Thanks for the patch.

On Tue, Jan 30, 2018 at 3:05 PM, Andre Przywara  wrote:
> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
> "reg" property from scratch using our previously parsed and
> translated(!) host addresses. However we then write the *absolute*
> addresses into the new node, not considering possible "range" mappings
> in any of the GIC's parent nodes. So whenever one of the parents has a
> non-empty ranges property, Dom0 will wrongly translate the addresses.
> Properly incorporating the ranges properties sounds tedious, so let's
> just copy the first part of the reg property instead (as we do for GICv2),
> since the addresses for Dom0 are identical to those from the hardware.
>
> The mainline kernel DT for the Espressobin board with an Marvell 3720 SoC
> has the GIC in such an translated bus, so this patch allows this board
> to boot properly (after adding support for the SoC's UART).
>
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-v3.c | 29 +++--
>  1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a0d290b55c..6b17abd0a1 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1147,10 +1147,9 @@ static int gicv3_make_hwdom_dt_node(const struct 
> domain *d,
>  const struct dt_device_node *gic,
>  void *fdt)
>  {
> -const void *compatible = NULL;
> -uint32_t len;
> -__be32 *new_cells, *tmp;
> -int i, res = 0;
> +const void *compatible, *hw_reg;
> +uint32_t len, new_len;
> +int res;
>
>  compatible = dt_get_property(gic, "compatible", );
>  if ( !compatible )
> @@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct 
> domain *d,
>  if ( res )
>  return res;
>
> -len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
> +new_len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
>  /*
>   * GIC has two memory regions: Distributor + rdist regions
>   * CPU interface and virtual cpu interfaces accessesed as System 
> registers
>   * So cells are created only for Distributor and rdist regions
>   */
> -len = len * (d->arch.vgic.nr_regions + 1);
> -new_cells = xzalloc_bytes(len);
> -if ( new_cells == NULL )
> -return -FDT_ERR_XEN(ENOMEM);
> -
> -tmp = new_cells;
> -
> -dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
> +new_len = new_len * (d->arch.vgic.nr_regions + 1);
>
> -for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
> -dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
> - d->arch.vgic.rdist_regions[i].size);
> +hw_reg = dt_get_property(gic, "reg", );
> +if ( !hw_reg )
> +return -FDT_ERR_XEN(ENOENT);
> +if ( new_len > len )
> +   return -FDT_ERR_XEN(ERANGE);
>
> -res = fdt_property(fdt, "reg", new_cells, len);
> -xfree(new_cells);
> +res = fdt_property(fdt, "reg", hw_reg, new_len);
>  if ( res )
>  return res;
>
> --
> 2.14.1
>

Tested on Espresso bin:

Tested-by: Amit Singh Tomar 

Thanks
-Amit

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

Re: [Xen-devel] [PATCH] xen/arm: Fix platform name for Xilinx ZynqMP

[Amit Tomer]

Hi,

> I guess you mean: xilinx_zynqmp, ... ?

Sorry, I would fix and repost it.

Thanks for looking.

-Amit

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