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
