On Thu, Nov 21, 2024 at 11:14:23AM +0000, Andrew Cooper wrote:
> On 21/11/2024 11:08 am, Roger Pau Monné wrote:
> > On Thu, Nov 21, 2024 at 11:54:49AM +0100, Jan Beulich wrote:
> >> 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.
> > Sure, what about adding to the commit message:
> >
> > "While PVH dom0 doesn't have access to the hypercalls to manage pIRQs
> > itself, neither the knowledge to do so, pIRQs are still used by Xen to
> > map and bind interrupts to a PVH dom0 behind its back. Hence the
> > pIRQ limit is still relevant for a PVH dom0."
>
> Minor grammar point. You want "nor" rather than "neither" in this
> context, because it's introducing the second of two negative things.
Thanks! Could one of you adjust at commit if Jan agrees with adding
the paragraph?
Regards, Roger.
