RE: [PATCH 0/7] irqchip/gic-v3: LPI allocation refactoring

[Zhang, Lei]

Hi Marc

This patches is necessary for our device, thanks a lot for your patches.
We have done the tests for your patches on our prototype CPU chip.
All of tests's results are PASSED.

Below is the detail of our tests.
We did tests for 2 points.
point 1: No level down for existing device such as nvme, network interface card.
what we did: iozone benchmark on nvme, ssh command.
point 2: Our original device can work well.
what we did: Test set for our original device.

And we have done the review, we think the patches is no problem.
But we found a spelling mistake in you comments.
> + * The consequence of the above is that allocation is cost is low, but
I propose the following is correct.

+ * The consequence of the above is that allocation cost is low, but

Best Regards,
Lei Zhang

> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx]
> Sent: Wednesday, June 20, 2018 10:52 PM
> To: linux-kernel@xxxxxxxxxxxxxxx
> Cc: Thomas Gleixner; Ard Biesheuvel; Shanker Donthineni; Shameer
> Kolothum; MaJun; Laurentiu Tudor; Zhang, Lei/張 雷
> Subject: [PATCH 0/7] irqchip/gic-v3: LPI allocation refactoring
> 
> The GICv3 LPI allocator has served us well so far, but a number of new
> use cases have recently showed up:
> 
> - A new extension to the GICv3 architecture allows a hypervisor to
>   dramatically restrict the range of available LPIs. This means that
>   our current policy of allocating LPIs in blocks of 32 may quickly
>   deplete the number of devices that get LPIs
> 
> - New and currently undisclosed busses seem to come with thousands of
>   devices, each requiring a single LPI. Again, our current allocation
>   policy means they quickly run out of LPIs.
> 
> Simply expanding the bitmap doesn't seem to be a great idea, so let's
> change the LPI allocator altogether. This means we can move individual
> busses to a more minimal allocation scheme, though we only do it for
> PCI at the moment (Platform MSI looks like the Far West, and I'm
> clueless about the FSL MC thing).
> 
> This is a pretty invasive change, and I'm thus cc'ing the usual
> suspects that have access to weird and wonderful HW to verify
> everything still works as expected, and let me know if we can relax
> the allocation for their own pet bus implementation.
> 
> Only lightly tested in a KVM guest (PCI).
> 
> 
> Marc Zyngier (7):
>   irqchip/gic-v3-its: Refactor LPI allocator
>   irqchip/gic-v3-its: Use full range of LPIs
>   irqchip/gic-v3-its: Move minimum LPI requirements to individual busses
>   irqchip/gic-v3-its: Drop chunk allocation compatibility
>   irqchip/gic-v3: Expose GICD_TYPER in the rdist structure
>   irqchip/gic-v3-its: Honor hypervisor enforced LPI range
>   irqchip/gic-v3-its: Reduce minimum LPI allocation to 1 for PCI devices
> 
>  drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c   |   3 +
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c      |  16 +-
>  drivers/irqchip/irq-gic-v3-its-platform-msi.c |   2 +
>  drivers/irqchip/irq-gic-v3-its.c              | 225
> ++++++++++++------
>  drivers/irqchip/irq-gic-v3.c                  |   4 +-
>  include/linux/irqchip/arm-gic-v3.h            |   3 +-
>  6 files changed, 169 insertions(+), 84 deletions(-)
> 
> --
> 2.17.1
> 
>