Re: [RFC XEN PATCH v4 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.01.2024 01:54, Stefano Stabellini wrote:
> On Fri, 5 Jan 2024, Jiqian Chen wrote:
>> On PVH dom0, the gsis don't get registered, but
>> the gsi of a passthrough device must be configured for it to
>> be able to be mapped into a hvm domU.
>> On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
>> passthrough devices to register gsi when dom0 is PVH.
>> So, add PHYSDEVOP_setup_gsi for above purpose.
>>
>> Co-developed-by: Huang Rui <ray.huang@xxxxxxx>
>> Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx>
>> ---
>>  xen/arch/x86/hvm/hypercall.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
>> index 632a68be3cc4..e27d3ca15185 100644
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -97,6 +97,12 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
>> arg)
>>          break;
>>      }
>>  
>> +    case PHYSDEVOP_setup_gsi:
>> +        if ( is_hardware_domain(currd) && !has_pirq(currd) )
>> +            break;
>> +        else
>> +            return -ENOSYS;
> 
> I am not sure what is the best "if" check for this situation but I am
> guessing we don't need has_pirq(currd). Maybe this is sufficient:
> 
> if ( is_hardware_domain(currd) )
>     break;
> else
>     return -ENOSYS;

Maybe

    if ( !is_hardware_domain(currd) )
        return -EOPNOTSUPP;
    ASSERT(!has_pirq(currd));
    break;

? What I primarily dislike in both earlier proposals is the (imo
confusing) use of "else".

Jan