Re: [PATCH v4 for-4.19? 2/2] cmdline: "extra_guest_irqs" is inapplicable to PVH

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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@xxxxxxxxxx>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> ---
> >> 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.