Hi Alex, On 4/4/2023 11:24 AM, Alex Williamson wrote: > We're talking about the contexts that we now allocate in the xarray to > store the eventfd linkage, right? We need to pre-allocate some irqs > both to satisfy the API and to support non-dynamic MSI-X devices, but > we don't need to pre-allocate contexts. The logic that I propose below > supports lookup of the pre-allocated irqs for all cases and falls back > to allocating a new irq only for cases that support it. irqs and > contexts aren't exactly 1:1 for the dynamic case due to the artifacts > of the API, but the model supports only allocating contexts as they're > used, or "active". Now I understand. Thank you very much for your patience. ... > Interrupts and contexts allocated together would be ideal, but I think > given the API it's a reasonable and simple compromise given the > non-dynamic support to draw from the initial allocation where we can. > Actually, there could be a latency and reliability advantage to hang on > to the irq when an eventfd is unset, maybe we should only free irqs on > MSI-X teardown and otherwise use the allocated irqs as a cache. Maybe > worth thinking about. Thanks, I implemented this change and I think it looks good. Enabling of dynamic MSI-X ended up consisting out of vfio_pci_alloc_irq() you suggested and one more line that uses it. This is because I also made the change to defer freeing irqs to MSI-X teardown and doing so is surely more efficient in the scenario that Jing pointed out. I did not transition the INTx code to "active" contexts - meaning that the interrupt context continues to be allocated at the time INTx is enabled. From what I understand the additional support for mask/unmask requires a context but it does not need to be active. Reinette