On Fri, 20 Jan 2017, Julien Grall wrote:
> Hi Stefano,
>
> Sorry for the late answer, still going through my e-mail backlog.
>
> On 06/01/2017 21:20, Stefano Stabellini wrote:
> > On Fri, 6 Jan 2017, Andre Przywara wrote:
> > > > It is also possible to end up calling mapti with an inexistent
Hi Stefano,
Sorry for the late answer, still going through my e-mail backlog.
On 06/01/2017 21:20, Stefano Stabellini wrote:
On Fri, 6 Jan 2017, Andre Przywara wrote:
It is also possible to end up calling mapti with an inexistent eventid
for host_devid. Could that be a problem?
Not at all.
On Fri, 6 Jan 2017, Andre Przywara wrote:
> >> +/* LPIs on the host always go to a guest, so no struct irq_desc for them.
> >> */
> >> +union host_lpi {
> >> +uint64_t data;
> >> +struct {
> >> +uint64_t virt_lpi:32;
> >> +uint64_t dom_id:16;
> >> +uint64_t
Hi,
On 05/01/17 18:56, Stefano Stabellini wrote:
> On Thu, 22 Dec 2016, Andre Przywara wrote:
> 7> 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
On Thu, 22 Dec 2016, Andre Przywara wrote:
7> 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,
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
