From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: Size of irq field Date: Thu, 2 Apr 2015 16:34:58 +0100 Message-ID: <551D61A2.6020201@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Iurii Konovalenko , Julien Grall Cc: Embedded-pv-devel@lists.xenproject.org, Stefano Stabellini , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org (CC Stefano and Ian) On 02/04/2015 16:05, Iurii Konovalenko wrote: > Hi, Julien! Hello Iurii, > > During bringing up Xen on Renesas Lager board we faced with problem. > A lot of Xen sources relies on statement, that IRQ number is less then > 256 and variables, parameters, fields etc. are of type uint8_t. But we > can have IRQs, that are greater then 255, for example on RCar H2 SoC. > Also, as I saw from one of your latest commits, GICv supports 1020 > physical interrupts. As a result, overflow can occur. So it seems > logical to increase all irq staff to uint16_t or uint32_t. We have > local patches for increasing some structures, functions etc. > But before pushing these patches I want to know your opinion, what do > you think about this problem? What type should we use uint16_t or > uint32_t? How to find all places where uint8_t type is used for IRQ? I'm a bit surprised. I looked through the hypervisor and libxl and I was able to found only one place (DOMCTL_irq_permission which is not really supported on ARM). We are usually using uint32_t/int for IRQ. Can you give an example of files/structures using uint8_t for IRQ? Ideally the IRQ should use uint32_t. This is allow us to support LPIs (IRQ number start a 8192 up to a very high number). > Best regards. Regards, -- Julien Grall