| Message ID | e95ea1ea-dd11-4994-9d50-308db4c3772e@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | new extra_guest_irqs adjustment | expand |
On Tue, Jul 02, 2024 at 11:52:38AM +0200, Jan Beulich wrote: > PVH in particular has no (externally visible) notion of pIRQ-s. Mention > that in the description of the respective command line option and have > arch_hwdom_irqs() also reflect this (thus suppressing the log message > there as well, as being pretty meaningless in this case anyway). > > Suggested-by: Roger Pau Monné <roger.pau@citrix.com> > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > Since the EOI map physdevop-s aren't available to HVM no matter whether > the PVH sub-flavor is meant, the condition could in principle be without > the has_pirq() part. Just that there really isn't any "pure HVM" Dom0. > --- > v4: New. > > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1178,7 +1178,8 @@ versa. For example to change dom0 witho > 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. > +to use the default. Note further that the Dom0 setting has no useful meaning > +for the PVH case; use of the option may have an adverse effect there, though. I would maybe remove the has_pirq() check and just mention in the comment added ahead of the is_hvm_domain() check that PVH/HVM guests never have access to the PHYSDEVOP_pirq_eoi_gmfn_v{1,2} hypercall, regardless of whether XENFEAT_hvm_pirqs is exposed. Would that be OK with you? Thanks, Roger.
On 03.07.2024 09:51, Roger Pau Monné wrote: > On Tue, Jul 02, 2024 at 11:52:38AM +0200, Jan Beulich wrote: >> PVH in particular has no (externally visible) notion of pIRQ-s. Mention >> that in the description of the respective command line option and have >> arch_hwdom_irqs() also reflect this (thus suppressing the log message >> there as well, as being pretty meaningless in this case anyway). >> >> Suggested-by: Roger Pau Monné <roger.pau@citrix.com> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> Since the EOI map physdevop-s aren't available to HVM no matter whether >> the PVH sub-flavor is meant, the condition could in principle be without >> the has_pirq() part. Just that there really isn't any "pure HVM" Dom0. >> --- >> v4: New. >> >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -1178,7 +1178,8 @@ versa. For example to change dom0 witho >> 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. >> +to use the default. Note further that the Dom0 setting has no useful meaning >> +for the PVH case; use of the option may have an adverse effect there, though. > > I would maybe remove the has_pirq() check and just mention in the > comment added ahead of the is_hvm_domain() check that PVH/HVM guests > never have access to the PHYSDEVOP_pirq_eoi_gmfn_v{1,2} hypercall, > regardless of whether XENFEAT_hvm_pirqs is exposed. > > Would that be OK with you? Okay-ish. That's why I had the post-commit-message remark on this very aspect. Jan
On Wed, Jul 03, 2024 at 10:00:51AM +0200, Jan Beulich wrote: > On 03.07.2024 09:51, Roger Pau Monné wrote: > > On Tue, Jul 02, 2024 at 11:52:38AM +0200, Jan Beulich wrote: > >> PVH in particular has no (externally visible) notion of pIRQ-s. Mention > >> that in the description of the respective command line option and have > >> arch_hwdom_irqs() also reflect this (thus suppressing the log message > >> there as well, as being pretty meaningless in this case anyway). > >> > >> Suggested-by: Roger Pau Monné <roger.pau@citrix.com> > >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > >> --- > >> Since the EOI map physdevop-s aren't available to HVM no matter whether > >> the PVH sub-flavor is meant, the condition could in principle be without > >> the has_pirq() part. Just that there really isn't any "pure HVM" Dom0. > >> --- > >> v4: New. > >> > >> --- a/docs/misc/xen-command-line.pandoc > >> +++ b/docs/misc/xen-command-line.pandoc > >> @@ -1178,7 +1178,8 @@ versa. For example to change dom0 witho > >> 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. > >> +to use the default. Note further that the Dom0 setting has no useful meaning > >> +for the PVH case; use of the option may have an adverse effect there, though. > > > > I would maybe remove the has_pirq() check and just mention in the > > comment added ahead of the is_hvm_domain() check that PVH/HVM guests > > never have access to the PHYSDEVOP_pirq_eoi_gmfn_v{1,2} hypercall, > > regardless of whether XENFEAT_hvm_pirqs is exposed. > > > > Would that be OK with you? > > Okay-ish. That's why I had the post-commit-message remark on this very aspect. I think adding the has_pirq() check is confusing, as the option is not available to PVH. Even if it was available it won't change the fact that PHYSDEVOP_pirq_eoi_gmfn_v{1,2} hypercall is not reachable. Thanks, Roger.
--- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1178,7 +1178,8 @@ versa. For example to change dom0 witho 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. +to use the default. Note further that the Dom0 setting has no useful meaning +for the PVH case; use of the option may have an adverse effect there, though. ### ext_regions (Arm) > `= <boolean>` --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -2669,6 +2669,10 @@ unsigned int __hwdom_init arch_hwdom_irq if ( is_system_domain(d) ) return max_irqs; + /* PVH isn't constrained by the EOI map. */ + if ( is_hvm_domain(d) && !has_pirq(d) ) + return nr_irqs; + if ( !d->domain_id ) n = min(n, dom0_max_vcpus()); n = min(nr_irqs_gsi + n * NR_DYNAMIC_VECTORS, min(nr_irqs, max_irqs));
PVH in particular has no (externally visible) notion of pIRQ-s. Mention that in the description of the respective command line option and have arch_hwdom_irqs() also reflect this (thus suppressing the log message there as well, as being pretty meaningless in this case anyway). Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Since the EOI map physdevop-s aren't available to HVM no matter whether the PVH sub-flavor is meant, the condition could in principle be without the has_pirq() part. Just that there really isn't any "pure HVM" Dom0. --- v4: New.