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

Re: [Xen-devel] [PATCH 10/18] xen/arm: Implement GIC suspend/resume functions (gicv2 only)


On 14/11/2018 22:18, Stefano Stabellini wrote:
> On Wed, 14 Nov 2018, Julien Grall wrote:
>>>>>    @@ -1319,6 +1341,129 @@ static void gicv2_do_LPI(unsigned int lpi)
>>>>>        BUG();
>>>>>    }
>>>>>    +static void gicv2_alloc_context(struct gicv2_context *gc)
>>>>> +{
>>>> Is it necessary to allocate them at boot? Can we make them static or
>>>> allocate them when we suspend?
>>> We need to allocate dynamically because the size of allocated data depends
>>> on the number of irq lines, which is not known at the compile time.
>> Well you know the upper bound. Why can't you use the upper bound?
>>> Alternative is to allocate on suspend, but I believe it is better to do this
>>> when the system boots.
>> Why is it better?
> I'll reply here also to your other point because they are related:
>> Suspend/resume is not a critical feature in common case. So I would
>> prefer if we disable it when we can't alloc memory.
> It is true that suspend/resume is not a critical feature for the common
> case, but proceeding as "normal" when a memory allocation fails is not a
> good idea: if the hypervisor is so low in memory as to fail in an
> allocation like this one, it is not going to be able to work right. In
> no other cases in Xen we continue on memory allocation failures, even
> for less-critical features.
> I suggest that we either allocate statically using the upper bound as
> you suggested, although it leads to some memory being wasted.

We are speaking of at most 2KB of memory. I don't think it is going to 
be waste given of the number of interrupts GIC usually supports.

The more that we already statically allocate irq_desc.


Julien Grall
Xen-devel mailing list



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