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....@citrix.com> >> Signed-off-by: Jan Beulich <jbeul...@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