>>> 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 summary for you: we need to allocate a 56 bytes struc
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 potential interrupt inject
>>> 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 guests
> (dom0 and domUs). Wit
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
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 could
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 need
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 pending_i
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 zero
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;
+
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;
> >> +
> >> +spin_lock(&v->arch.vgic.pending_lpi_list_l
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 cann
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
>> #i
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_* hea
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 fea
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 an
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 injec
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
17 matches
Mail list logo