[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 |