Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

>>> On 28.03.17 at 15:12, wrote: > Hi Jan, > > On 28/03/17 08:58, Jan Beulich wrote: > On 27.03.17 at 20:39, wrote: >>> CC'ing Andrew, Jan and George to get more feedback on the security >>> impact of this patch. >>> >>> I'll make a quick

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Jan, On 28/03/17 08:58, Jan Beulich wrote: On 27.03.17 at 20:39, wrote: CC'ing Andrew, Jan and George to get more feedback on the security impact of this patch. I'll make a quick summary for you: we need to allocate a 56 bytes struct (called pending_irq) for each

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

>>> On 27.03.17 at 20:39, wrote: > CC'ing Andrew, Jan and George to get more feedback on the security > impact of this patch. > > I'll make a quick summary for you: we need to allocate a 56 bytes struct > (called pending_irq) for each potential interrupt injected to

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Stefano, On 27/03/2017 19:39, Stefano Stabellini wrote: On Mon, 27 Mar 2017, Julien Grall wrote: For both guest could potentially flood us. It would take us a lot of time to allocate/free memory for each vLPIs modified. Hence, why I didn't suggest it and said: "One could argue that we could

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

CC'ing Andrew, Jan and George to get more feedback on the security impact of this patch. I'll make a quick summary for you: we need to allocate a 56 bytes struct (called pending_irq) for each potential interrupt injected to guests (dom0 and domUs). With the new ARM interrupt controller there

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Stefano, On 27/03/17 18:44, Stefano Stabellini wrote: On Mon, 27 Mar 2017, Julien Grall wrote: Hi, On 27/03/17 10:02, Andre Przywara wrote: On 24/03/17 17:26, Stefano Stabellini wrote: On Fri, 24 Mar 2017, Andre Przywara wrote: I am afraid that this would lead to situations where we

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Mon, 27 Mar 2017, Julien Grall wrote: > Hi, > > On 27/03/17 10:02, Andre Przywara wrote: > > On 24/03/17 17:26, Stefano Stabellini wrote: > > > On Fri, 24 Mar 2017, Andre Przywara wrote: > > I am afraid that this would lead to situations where we needlessly > > allocate and deallocate

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi, On 27/03/17 10:02, Andre Przywara wrote: On 24/03/17 17:26, Stefano Stabellini wrote: On Fri, 24 Mar 2017, Andre Przywara wrote: I am afraid that this would lead to situations where we needlessly allocate and deallocate pending_irqs. Under normal load I'd expect to have something like

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi, On 24/03/17 17:26, Stefano Stabellini wrote: > On Fri, 24 Mar 2017, Andre Przywara wrote: +struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi, + bool allocate) +{ +struct lpi_pending_irq *lpi_irq, *empty = NULL; +

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Fri, 24 Mar 2017, Andre Przywara wrote: > >> +struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi, > >> + bool allocate) > >> +{ > >> +struct lpi_pending_irq *lpi_irq, *empty = NULL; > >> + > >> +

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Andre, On 03/24/2017 03:50 PM, Andre Przywara wrote: On 24/03/17 11:40, Julien Grall wrote: +/* + * Holding struct pending_irq's for each possible virtual LPI in each domain + * requires too much Xen memory, also a malicious guest could potentially + * spam Xen with LPI map requests. We

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi, On 24/03/17 11:40, Julien Grall wrote: > Hi Andre > > On 03/16/2017 11:20 AM, Andre Przywara wrote: >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c >> index 364d5f0..e5cfa54 100644 >> --- a/xen/arch/arm/vgic.c >> +++ b/xen/arch/arm/vgic.c >> @@ -30,6 +30,8 @@ >> >> #include >>

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Andre On 03/16/2017 11:20 AM, Andre Przywara wrote: diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 364d5f0..e5cfa54 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -30,6 +30,8 @@ #include #include +#include +#include I really don't want to see gic_v3_*

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Andre, On 03/23/2017 08:08 PM, André Przywara wrote: On 22/03/17 23:44, Stefano Stabellini wrote: On Thu, 16 Mar 2017, Andre Przywara wrote: For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

On 22/03/17 23:44, Stefano Stabellini wrote: > On Thu, 16 Mar 2017, Andre Przywara wrote: >> For the same reason that allocating a struct irq_desc for each >> possible LPI is not an option, having a struct pending_irq for each LPI >> is also not feasible. However we actually only need those when

Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Thu, 16 Mar 2017, Andre Przywara wrote: > For the same reason that allocating a struct irq_desc for each > possible LPI is not an option, having a struct pending_irq for each LPI > is also not feasible. However we actually only need those when an > interrupt is on a vCPU (or is about to be

[Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. However we actually only need those when an interrupt is on a vCPU (or is about to be injected). Maintain a list of those structs that we can