On 12.12.2023 07:49, Chen, Jiqian wrote:
> On 2023/12/11 23:31, Roger Pau Monné wrote:
>> On Mon, Dec 11, 2023 at 12:40:08AM +0800, Jiqian Chen wrote:
>>> --- a/xen/arch/x86/hvm/hypercall.c
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -72,8 +72,11 @@ long hvm_physdev_op(int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
>>> switch ( cmd )
>>> {
>>> + case PHYSDEVOP_setup_gsi:
>>
>> I think given the new approach on the Linux side patches, where
>> pciback will configure the interrupt, there's no need to expose
>> setup_gsi anymore?
> The latest patch(the second patch of v3 on kernel side) does setup_gsi and
> map_pirq for passthrough device in pciback, so we need this and below.
>
>>
>>> case PHYSDEVOP_map_pirq:
>>> case PHYSDEVOP_unmap_pirq:
>>> + if ( is_hardware_domain(currd) )
>>> + break;
>>
>> Also Jan already pointed this out in v2: this hypercall needs to be
>> limited so a PVH dom0 cannot execute it against itself. IOW: refuse
>> the hypercall if DOMID_SELF or the passed domid matches the current
>> domain domid.
> Yes, I remember Jan's suggestion, but since the latest patch(the second patch
> of v3 on kernel side) has change the implementation, it does setup_gsi and
> map_pirq for dom0 itself, so I didn't add the DOMID_SELF check.
And why exactly would it do specifically the map_pirq? (Even the setup_gsi
looks questionable to me, but there might be reasons there.)
Jan
