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

Re: [PATCH] xen/arm: Do not include in the image functions...



Hi Julien,

On 06.12.2021 17:40, Julien Grall wrote:
> 
> 
> On 06/12/2021 15:00, Michal Orzel wrote:
>> Hi Julien,
> 
> Hi Michal,
> 
>> On 06.12.2021 15:39, Julien Grall wrote:
>>> Hi Michal,
>>>
>>> On 06/12/2021 14:19, Michal Orzel wrote:
>>>> vtimer_update_irqs, vtimer_update_irq and vcpu_update_evtchn_irq if
>>>> CONFIG_NEW_VGIC is not set.
>>>>
>>>> enter_hypervisor_from_guest is protecting calls to these functions
>>>> with CONFIG_NEW_VGIC but their definitions and declarations are not > 
>>>> protected. This means that we are including them in the image even
>>>> though we are not making use of them. Fix that.
>>>
>>> While I agree, they are only used by the new vGIC, the implementation of 
>>> the functions are not. So I don't think they should be protected by 
>>> CONFIG_NEW_VGIC.
>>>
>>> Actually, I am not convinced they should be protected. But I guess you did 
>>> that for a reason. Would you be able to clarify what is your reason?
>>>
>>  From what I know + what the commit introducing these fucntions states 
>> (b9db96f71a74), the current vGIC does not handle level-triggered vIRQs.
>> The functionality of these functions is only related to new VGIC 
>> implementation which can handle level triggered vIRQs.
> 
> This is a known error in the vGIC implementation which should be resolved 
> before this leads to a disaster.

I just thought that if this error is present for such a long time, there are no 
plans to make current vgic handle level type irqs.
> 
>> So I do not think that these functions are generic and thus I believe they 
>> should be protected.
> 
> None of the functions rely on the internal of the new vGIC. In fact, as I 
> wrote above, the current vGIC ought to be able to handle level-trigger 
> interrupt properly.
> 
> They are not called for the current vGIC because there was concern about the 
> performance impact on each trap (see [1]).
> 
> So I think those functions ought to stay compiled in for everyone.
> 
I'm totally ok with that.

> Cheers,
> 
> [1] 
> https://lore.kernel.org/xen-devel/22601816-8235-7891-b634-4af5348a1337@xxxxxxx/
> 
> 
> 
>>> Cheers,
>>>
>>
>> Cheers,
>> Michal
>>
> 

Cheers,
Michal



 


Rackspace

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