Hello!
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of Andre Przywara
> Sent: Wednesday, October 07, 2015 5:55 PM
> To: marc.zyng...@arm.com; christoffer.d...@linaro.org
> Cc: eric.au...@linaro.org; p.fe...@samsung.com;
Hello!
> Shouldn't we also have 'break' here? If vgic_queue_irq() returns false, this
> means we have no
> more
> LRs to use, therefore it makes no sense to keep iterating.
No, don't listen to me. :) Because of piggyback, we indeed have to recheck all
the interrupts.
P.S. I still
Hi Pavel,
On 12/10/15 08:40, Pavel Fedin wrote:
> Hello!
>
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
>> Of Andre Przywara
>> Sent: Wednesday, October 07, 2015 5:55 PM
>> To: marc.zyng...@arm.com; christoffer.d...@linaro.org
>>
On 07/10/15 16:10, Pavel Fedin wrote:
> Hello!
>
>> As the actual LPI number in a guest can be quite high, but is mostly
>> assigned using a very sparse allocation scheme, bitmaps and arrays
>> for storing the virtual interrupt status are a waste of memory.
>> We use our equivalent of the
Hello!
> As the actual LPI number in a guest can be quite high, but is mostly
> assigned using a very sparse allocation scheme, bitmaps and arrays
> for storing the virtual interrupt status are a waste of memory.
> We use our equivalent of the "Interrupt Translation Table Entry"
> (ITTE) to hold
On 07/10/15 16:46, Pavel Fedin wrote:
> Hello!
>
>> Sure. And you then have to parse and validate all the tables each and
>> every time you're going to inject an interrupt (because the guest can
>> change the table content behind your back). You are quickly going to
>> notice that your
Hello!
> Sure. And you then have to parse and validate all the tables each and
> every time you're going to inject an interrupt (because the guest can
> change the table content behind your back). You are quickly going to
> notice that your performance is abysmal.
I don't see any real
