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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan