linux-kernel - Re: ITS restore/save state when HCC == 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 3 Dec 2019 10:23:12 +0800
From:   Yao HongBo <yaohongbo@...wei.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     "Guohanjun (Hanjun Guo)" <guohanjun@...wei.com>,
        Yangyingliang <yangyingliang@...wei.com>,
        Linuxarm <linuxarm@...wei.com>, <linux-kernel@...r.kernel.org>
Subject: Re: ITS restore/save state when HCC == 0



On 12/2/2019 9:22 PM, Marc Zyngier wrote:
> Hi Yaohongbo,
> 
> In the future, please refrain from sending HTML emails, they
> don't render very well and force me to reformat your email
> by hand.

Sorry. I'll pay attention to this next time.

> On 2019-12-02 12:52, yaohongbo wrote:
>> Hi, marc.
>>
>> I met a problem with GIC ITS when I try to power off gic logic in
>> suspend.
>>
>> In hisilicon hip08, the value of GIC_TYPER.HCC is zero, so that
>> ITS_FLAGS_SAVE_SUSPEND_STATE will have no chance to be set to 1.
> 
> And that's a good thing. HCC indicates that you have collections that
> are backed by registers, and not memory. Which means that once the GIC
> is powered off, the state is lost.
> 
>> It goes well for s4, when I simply remove the condition judgement in
>> the code.
> 
> What is "s4"? Doing so means you are reprogramming the ITS with mappings
> that already exist in the tables, and that is UNPRED territory.

Sorry, I didn't describe it clearly.
S4 means "suspend to disk".
In s4, The its will reinit and malloc an new its address.

My expectation is to reprogram the ITS with original mappings. If ITS_FLAGS_SAVE_SUSPEND_STATE
is not set, i'll have no chance to use the original its table mappings.

What should i do if i want to restore its state with hcc == 0?

Thanks,
Hongbo.
> <quote>
> Behavior is unpredictable if there are interrupts that are mapped to the
> specified collection and the collection is currently mapped to a Redistributor
> [...]
> </quote>
> 
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>
>> @@ -3670,8 +3670,8 @@ static int __init its_probe_one(struct resource
>> *res,
>>
>>  ctlr |= GITS_CTLR_ImDe;
>>
>>  writel_relaxed(ctlr, its->base + GITS_CTLR);
>>
>> - if (GITS_TYPER_HCC(typer))
>>
>> - its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE;
>>
>> + its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE;
>>
>>  err = its_init_domain(handle, its);
>>
>>  if (err)
>>
>> @@ -4005,3 +4005,17 @@ int __init its_init(struct fwnode_handle
>> *handle, struct rdists *rdists,
>>
>>  return 0;
>>
>> }
>>
>> Do you have any suggestion for this case?
> 
> The expectations are that across a GIC power-off, the firmware
> will restore the state of the GIC (recondiguring the various
> memory tables), and that this is enough for the ITS to be
> functional again, having reloaded its state from memory.
> 
> Does firmware perform this on your machine? Or are there
> implementation-specific issues that require the ITS to be
> reprogrammed?
> 
> Thanks,
> 
>         M.