On 04/03/2017 08:30 PM, Andre Przywara wrote:
Hi,
Hi Andre,
On 23/03/17 19:08, Julien Grall wrote:
/*
+ * On the host ITS @its, map @nr_events consecutive LPIs.
+ * The mapping connects a device @devid and event @eventid pair to
LPI @lpi,
+ * increasing both @eventid and @lpi to cover the n
Hi,
On 23/03/17 19:08, Julien Grall wrote:
> Hi Andre,
>
> On 16/03/17 11:20, Andre Przywara wrote:
>> The number of LPIs on a host can be potentially huge (millions),
>> although in practise will be mostly reasonable. So prematurely allocating
>> an array of struct irq_desc's for each LPI is not
Hi Stefano,
On 03/23/2017 05:52 PM, Stefano Stabellini wrote:
On Thu, 23 Mar 2017, Andre Przywara wrote:
On Thu, 23 Mar 2017, Julien Grall wrote:
Not answering directly to the question. But I think this is an improvement and
not necessary for a first version.
I would like to see this series me
Hi Andre,
On 16/03/17 11:20, Andre Przywara wrote:
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs,
On Thu, 23 Mar 2017, Andre Przywara wrote:
> Hi,
>
> On 22/03/17 23:38, Stefano Stabellini wrote:
> > On Thu, 16 Mar 2017, Andre Przywara wrote:
> >> The number of LPIs on a host can be potentially huge (millions),
> >> although in practise will be mostly reasonable. So prematurely allocating
> >>
Hi,
On 22/03/17 23:38, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Andre Przywara wrote:
>> The number of LPIs on a host can be potentially huge (millions),
>> although in practise will be mostly reasonable. So prematurely allocating
>> an array of struct irq_desc's for each LPI is not an opt
Hi Stefano,
On 22/03/2017 23:38, Stefano Stabellini wrote:
On Thu, 16 Mar 2017, Andre Przywara wrote:
[...]
+dev->host_lpis = xzalloc_array(uint32_t,
+ DIV_ROUND_UP(nr_events, LPI_BLOCK));
+if ( !dev->host_lpis )
+goto out_unlock;
The expec
On Thu, 16 Mar 2017, Andre Przywara wrote:
> The number of LPIs on a host can be potentially huge (millions),
> although in practise will be mostly reasonable. So prematurely allocating
> an array of struct irq_desc's for each LPI is not an option.
> However Xen itself does not care about LPIs, as
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for n
