On 20.11.2024 12:35, Roger Pau Monne wrote:
> Do not return early in the PVH/HVM case, so that the number of pIRQs is also
> printed.
What you're printing ...
> Fixes: 17f6d398f765 ('cmdline: document and enforce "extra_guest_irqs" upper
> bounds')
> Signed-off-by: Roger Pau Monné <roger....@citrix.com>
> ---
> xen/arch/x86/io_apic.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
> index bd5ad61c85e4..d9db2efc4f58 100644
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2754,11 +2754,13 @@ unsigned int __hwdom_init arch_hwdom_irqs(const
> struct domain *d)
>
> /* PVH (generally: HVM) can't use PHYSDEVOP_pirq_eoi_gmfn_v{1,2}. */
> if ( is_hvm_domain(d) )
> - return nr_irqs;
> -
> - if ( !d->domain_id )
> - n = min(n, dom0_max_vcpus());
> - n = min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, max_irqs);
> + n = nr_irqs;
... is rather the number of IRQs we picked for the system. That may happen to
end up being the upper bound for PVH Dom0, yet not logging this at all was
because of the limited use pIRQ-s have there. Granted at the time I was still
under the impression they have no use there at all, so this isn't really an
objection to the change. I would have been nice though if the description had
mentioned why significance pIRQ-s actually have in PVH Dom0.
Jan
> + else
> + {
> + if ( !d->domain_id )
> + n = min(n, dom0_max_vcpus());
> + n = min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, max_irqs);
> + }
>
> printk("%pd has maximum %u PIRQs\n", d, n);
>
