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

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

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?

Thanks, Roger.