Re: [Bug] Bring up Dom0 on Arm board

["蔡力刚" <cai_ligang@xxxxxxxxxxxxxxx>]

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 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.

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>;
    };
};

Best regards

Cailigang