|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 3/3] cmdline: document and enforce "extra_guest_irqs" upper bounds
On Thu, Jul 27, 2023 at 09:38:55AM +0200, Jan Beulich wrote:
> PHYSDEVOP_pirq_eoi_gmfn_v<N> accepting just a single GFN implies that no
> more than 32k pIRQ-s can be used by a domain on x86. Document this upper
> bound.
>
> To also enforce the limit, (ab)use both arch_hwdom_irqs() (changing its
> parameter type) and setup_system_domains(). This is primarily to avoid
> exposing the two static variables or introducing yet further arch hooks.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Instead of passing dom_xen into arch_hwdom_irqs(), NULL could also be
> used. That would make the connection to setup_system_domains() yet more
> weak, though.
>
> Passing the domain pointer instead of the domain ID would also allow
> to return a possibly different value if sensible for PVH Dom0 (which
> presently has no access to PHYSDEVOP_pirq_eoi_gmfn_v<N> in the first
> place).
> ---
> v2: Also enforce these bounds. Adjust doc to constrain the bound to x86
> only. Re-base over new earlier patch.
>
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1146,7 +1146,8 @@ common for all domUs, while the optional
> is for dom0. Changing the setting for domU has no impact on dom0 and vice
> versa. For example to change dom0 without changing domU, use
> `extra_guest_irqs=,512`. The default value for Dom0 and an eventual separate
> -hardware domain is architecture dependent.
> +hardware domain is architecture dependent. The upper limit for both values
> on
> +x86 is such that the resulting total number of IRQs can't be higher than
> 32768.
> Note that specifying zero as domU value means zero, while for dom0 it means
> to use the default.
>
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2663,18 +2663,21 @@ void __init ioapic_init(void)
> nr_irqs_gsi, nr_irqs - nr_irqs_gsi);
> }
>
> -unsigned int arch_hwdom_irqs(domid_t domid)
> +unsigned int arch_hwdom_irqs(const struct domain *d)
While at it, should this be __hwdom_init?
I'm fine with changing the function to take a domain parameter...
> {
> unsigned int n = fls(num_present_cpus());
>
> - if ( !domid )
> + if ( is_system_domain(d) )
> + return PAGE_SIZE * BITS_PER_BYTE;
... but why do we need a function call just to get a constant value?
Wouldn't this better be a define in a header?
> +
> + if ( !d->domain_id )
> n = min(n, dom0_max_vcpus());
> n = min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, nr_irqs);
>
> /* Bounded by the domain pirq eoi bitmap gfn. */
> n = min_t(unsigned int, n, PAGE_SIZE * BITS_PER_BYTE);
So that could also use the same constant here?
> - printk("Dom%d has maximum %u PIRQs\n", domid, n);
> + printk("%pd has maximum %u PIRQs\n", d, n);
>
> return n;
> }
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -693,7 +693,7 @@ struct domain *domain_create(domid_t dom
> d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> else
> d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs +
> extra_hwdom_irqs
> - : arch_hwdom_irqs(domid);
> + : arch_hwdom_irqs(d);
> d->nr_pirqs = min(d->nr_pirqs, nr_irqs);
>
> radix_tree_init(&d->pirq_tree);
> @@ -819,6 +819,24 @@ void __init setup_system_domains(void)
> if ( IS_ERR(dom_xen) )
> panic("Failed to create d[XEN]: %ld\n", PTR_ERR(dom_xen));
>
> +#ifdef CONFIG_HAS_PIRQ
> + /* Bound-check values passed via "extra_guest_irqs=". */
> + {
> + unsigned int n = max(arch_hwdom_irqs(dom_xen), nr_static_irqs);
> +
> + if ( extra_hwdom_irqs > n - nr_static_irqs )
> + {
> + extra_hwdom_irqs = n - nr_static_irqs;
> + printk(XENLOG_WARNING "hwdom IRQs bounded to %u\n", n);
> + }
> + if ( extra_domU_irqs > max(32U, n - nr_static_irqs) )
> + {
> + extra_domU_irqs = n - nr_static_irqs;
> + printk(XENLOG_WARNING "domU IRQs bounded to %u\n", n);
> + }
> + }
> +#endif
IMO this is kind of a weird placement. Wouldn't this be more naturally
handled in parse_extra_guest_irqs()?
Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |