Re: [Bug] Bring up Dom0 on Arm board

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 1 Feb 2023, 蔡力刚 wrote:
> >> > 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 think you should try to find out which ones are the HVCs/SMCs that
> > need to be forwarded and which ones that need to be handled as usual.
> > 
> > Once you know that, you could write a platform driver like
> > xen/arch/arm/platforms/xilinx-zynqmp.c that handles things
> > appropriately.
> > 
> > 
> > > I have not idea how to find out 0x1000a0 where comes from, do you have 
> >any suggestions?
> > 
> > I would look at device tree to see within which range 0x1000a0 falls.
> 
> What I'm confused about is what's the difference between HVC/SMC calls 
> through xen forward to firmware and kernel HVC/SMC calls direct to firmware?
> If it's the same, then there should be no fault.

In theory with the last patch I sent you there should be no difference
between the HVC/SMC calls direct to firmware and the ones forwarded to
firmware by Xen. One thing you could try is to print out all the SMC/HVC
calls that are done on native and compared them against the ones done on
Xen to see if they match.

One difference however is memory mapping. If something like address
0x1000a0 is nomapped in the guest, then a failure is expected,


> I search the dtb and found a device may be related to 0x1000a0, content as 
> below:
> 
> sram@10f000 {
>     compatible = "mmio-sram";
>     reg = <0x00 0x10f000 0x00 0x100>;
>     #address-cells = <0x01>;
>     #size-cells = <0x01>;
>     ranges = <0x00 0x00 0x10f000 0x100>;
> 
>     sram@0 {
>         compatible = "arm,scmi-shmem";
>         reg = <0x00 0x100>;
>         phandle = <0x38>;
>     };
> };

What is the #address-cells and #size-cells of the parent node?

If it is #address-cells = 2 and #size-cells = 2, then this region is
0x10f000-0x110000. We need the region just before it.

It is possible that it exists but it is not described in device tree. In
that case it is normal to get an error when trying to access it.