[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug] Bring up Dom0 on Arm board



Hi,

> I think we have two problems here.

> One problem, which is a known problem, is that sometimes the kernel can
> make firmware calls (as SMC calls) to initialize a device driver. This
> is what the "forward_smc" suggestion was meant to solve.

> "forward_smc" is an effective workaround, but the proper solution would
> be to write a platform driver like zynqmp_eemi which check which SMC
> calls need to be forwarded and forward only those.

> The second problem is that the kernel is making firmware calls using HVC
> as transport instead of SMC. This is uncommon. That is the reason why
> "forward_smc" didn't work. "forward_smc" only forward SMC calls, not HVC
> calls.

> But if you had a platform driver like zynqmp_eemi, in theory the
> platform_smc() call in vsmccc_handle_call should have worked correctly
> for both SMC and HVC coming from Linux.

> Just to see if we understood the problem correctly, the appended patch
> alone (no need for other changes) should work, if you pass
> forward_firmware=true to the Xen command line.


> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 7335276f3f..1d11634bff 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -8,6 +8,7 @@
>  
>  
>  #include <xen/lib.h>
> +#include <xen/param.h>
>  #include <xen/types.h>
>  #include <public/arch-arm/smccc.h>
>  #include <asm/cpuerrata.h>
> @@ -26,6 +27,9 @@
>  /* Number of functions currently supported by Standard Service Service Calls. */
>  #define SSSC_SMCCC_FUNCTION_COUNT (3 + VPSCI_NR_FUNCS)
>  
> +static bool __read_mostly forward_fw = false;
> +boolean_param("forward_firmware", forward_fw);
> +
>  static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)
>  {
>      int n;
> @@ -224,6 +228,27 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
>      const union hsr hsr = { .bits = regs->hsr };
>      uint32_t funcid = get_user_reg(regs, 0);
>  
> +    if ( forward_fw )
> +    {
> +        struct arm_smccc_res res;
> +
> +        arm_smccc_1_1_smc(get_user_reg(regs, 0),
> +                          get_user_reg(regs, 1),
> +                          get_user_reg(regs, 2),
> +                          get_user_reg(regs, 3),
> +                          get_user_reg(regs, 4),
> +                          get_user_reg(regs, 5),
> +                          get_user_reg(regs, 6),
> +                          get_user_reg(regs, 7),
> +                          &res);
> +
> +        set_user_reg(regs, 0, res.a0);
> +        set_user_reg(regs, 1, res.a1);
> +        set_user_reg(regs, 2, res.a2);
> +        set_user_reg(regs, 3, res.a3);
> +        return true;
> +    }
> +

I tried the change above, but still has a fault in kernel, log as below:
The change is to pass all HVC and SMC calls forward to firmware,
but what I have tried successfully is passing all HVC calls and not handling all SMC calls.
I have not idea how to find out 0x1000a0 where comes from, do you have any suggestions?

(XEN) d0v0 hsr.ec 0x17
(XEN) d0v0 do_trap_smc trap....
(XEN) traps.c:1987:d0v0 HSR=0x92000007 pc=0xffffffc01069b830 gva=0xffffffc0126e30a0 gpa=0x000000001000a0
[    6.027388] Unhandled fault at 0xffffffc0126e30a0
[    6.027415] Mem abort info:
[    6.027490]   ESR = 0x96000000
[    6.027514]   EC = 0x25: DABT (current EL), IL = 32 bits
[    6.027537]   SET = 0, FnV = 0
[    6.027554]   EA = 0, S1PTW = 0
[    6.027571] Data abort info:
[    6.027589]   ISV = 0, ISS = 0x00000000
[    6.027607]   CM = 0, WnR = 0
[    6.027627] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000019484000
[    6.027652] [ffffffc0126e30a0] pgd=000000013ffff003, p4d=000000013ffff003, pud=000000013ffff003, pmd=0000000101d86003, pte=0068000000100717
[    6.027714] Internal error: ttbr address size fault: 96000000 [#1] SMP
[    6.027740] Modules linked in:
[    6.027766] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.66 #8
[    6.027790] Hardware name: Rockchip RK3588 EVB7 LP4 V10 Board (DT)
[    6.027819] pstate: 60c00005 (nZCv daif +PAN +UAO -TCO BTYPE=--)
[    6.027850] pc : rockchip_gem_get_ddr_info+0x28/0x40
[    6.027884] lr : rockchip_gem_get_ddr_info+0x1c/0x40
[    6.027905] sp : ffffffc011e7bd60
[    6.027923] x29: ffffffc011e7bd60 x28: 0000000000000000 
[    6.027952] x27: ffffffc011490438 x26: ffffffc0114f1070 
[    6.027981] x25: 0000000000000006 x24: ffffffc0115bf598 
[    6.028010] x23: 0000000000000000 x22: ffffffc011d56a40 
[    6.028039] x21: ffffffc011e34000 x20: 0000000000000000 
[    6.028067] x19: ffffffc011e34c30 x18: 0000000000000000 
[    6.028095] x17: 000000000000000e x16: 0000000000000007 
[    6.028124] x15: 000000000000000a x14: 0000000000000662 
[    6.028152] x13: ffffffffffffffff x12: ffffffffffffffff 
[    6.028181] x11: 0000000000000000 x10: ffffff8102730a1c 
[    6.028209] x9 : ffffffc010b26fe0 x8 : ffffffc011e7bd38 
[    6.028237] x7 : 0000000000000000 x6 : 0000000000000000 
[    6.028266] x5 : 0000000000000000 x4 : 0000000000000000 
[    6.028297] x3 : 0000000000000000 x2 : ffffffc011c99980 
[    6.028326] x1 : ffffffc011c99000 x0 : ffffffc0126e3000 
[    6.028355] Call trace:
[    6.028377]  rockchip_gem_get_ddr_info+0x28/0x40
[    6.028404]  rockchip_drm_init+0x110/0x114
[    6.028427]  do_one_initcall+0xa0/0x1e8
[    6.028450]  kernel_init_freeable+0x2a4/0x2ac
[    6.028475]  kernel_init+0x20/0x11c
[    6.028496]  ret_from_fork+0x10/0x30
[    6.028516] 
[    6.028516] PC: 0xffffffc01069b730:
[    6.028536] b730  aa0003f3 f9400400 f9402c14 f9412660 97eb302d f9412a60 97f7be94 f9412a60
[    6.028598] b750  97ec26a5 f9401280 d2800003 f9407662 f940c661 97f81021 a94153f3 a8c27bfd
[    6.028657] b770  d50323bf d65f03c0 aa1e03e9 d503201f d503233f a9bd7bfd d2804c02 910003fd
[    6.028716] b790  f90013f5 aa0003f5 d0006b20 a90153f3 2a0103f4 f945f800 5281b801 97ec22a5
[    6.028775] b7b0  b4000280 aa0003f3 51000682 32002c42 aa0003e1 11000442 aa1503e0 97ff3263
[    6.028835] b7d0  f9400a60 52819a41 72a00201 f9401000 f9401800 b9003001 aa1303e0 a94153f3
[    6.028894] b7f0  f94013f5 a8c37bfd d50323bf d65f03c0 92800173 17fffff9 d503245f aa1e03e9
[    6.028952] b810  d503201f d503233f a9bf7bfd 910003fd 941230e8 b40000c0 d000afe1 91260022
[    6.029011] b830  29540003 b9098020 b9000443 a8c17bfd d50323bf d65f03c0 d503245f aa1e03e9
[    6.029070] b850  d503201f d503233f a9be7bfd aa0103e2 910003fd a90153f3 aa0103f4 aa0003f3
[    6.029128] b870  f9407401 97ff34bd 35000080 aa1403e1 aa1303e0 97fffda7 a94153f3 a8c27bfd
[    6.029187] b890  d50323bf d65f03c0 d503245f aa1e03e9 d503201f d503233f a9be7bfd 910003fd
[    6.029255] b8b0  f9000bf3 aa0103f3 97ff34ec 350000a0 f9405660 f9004e7f aa1303e1 97fffd95
[    6.029314] b8d0  f9400bf3 a8c27bfd d50323bf d65f03c0 d503245f aa1e03e9 d503201f d503233f
[    6.029372] b8f0  a9bc7bfd 910003fd a90153f3 2a0303f4 a9025bf5 12001c55 a90363f7 97ffff9b

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.