On 15/07/2019 11:43, Guoheyi wrote:
>
>
> On 2019/7/15 17:07, Marc Zyngier wrote:
>> On 15/07/2019 07:32, Guoheyi wrote:
>>> Hi Marc,
>>>
>>> The issue only occurs after applying the vlpi_map_rework patches, and we
>>> can see the patches only affect VM; it changes its_create_device() a
>>> little so it may affect host booting in some ways, so I took the lazy
>>> way to send it out for some insights.
>>>
>>> I am suspecting below code; if alloc_lpis == false, what will happen?
>> If !alloc_lpis, then we don't allocate the lpi_map, which is the
>> intended effect.
>>
>>> Anyway, I will investigate more on this.
>>>
>>>
>>> if (alloc_lpis) {
>>> lpi_map = its_lpi_alloc(nvecs, &lpi_base, &nr_lpis);
>>> if (lpi_map)
>>> col_map = kcalloc(nr_lpis, sizeof(*col_map),
>>> GFP_KERNEL);
>>> } else {
>>> col_map = kcalloc(nr_ites, sizeof(*col_map), GFP_KERNEL);
>>> nr_lpis = 0;
>>> lpi_base = 0;
>>> }
>>> if (its->is_v4)
>>> vlpi_map = kcalloc(nr_lpis, sizeof(*vlpi_map), GFP_KERNEL);
>>>
>>> if (!dev || !itt || !col_map || (!lpi_map && alloc_lpis) ||
>>> (!vlpi_map && its->is_v4)) {
>>> kfree(dev);
>>> kfree(itt);
>>> kfree(lpi_map);
>>> kfree(col_map);
>>> kfree(vlpi_map);
>>> return NULL;
>>> }
>> How does this relate to the patch posted in this discussion? The
>> proposed changes turn the locking from a mutex into a raw_spinlock.
>
> I'm testing the patchset in
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/vlpi-map-rework,
>
> not only the patch posted in the mail directly. The first patch
> *"**irqchip/gic-v3-its: Make vlpi_map allocations atomic" works well in
> our internal tree, and my new testing is against the other 3 patches in
> your vlpi-map-rework branch, as I promised. I'm sorry if I didn't state
> this clearly.
Ah, I had completely forgot about this branch. As I said, it is
completely untested. I'll see if I can get some brain bandwidth in the
next couple of weeks to get back to it...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
