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

From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Daniel P . Smith" <dpsmith@apertussolutions.com>,
	"Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>,
	"Huang, Ray" <Ray.Huang@amd.com>,
	"Chen, Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [RFC XEN PATCH v5 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0
Date: Mon, 26 Feb 2024 06:04:01 +0000	[thread overview]
Message-ID: <BL1PR12MB58498142AF67EB5CE27F72AEE75A2@BL1PR12MB5849.namprd12.prod.outlook.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2402221642530.754277@ubuntu-linux-20-04-desktop>


On 2024/2/23 08:44, Stefano Stabellini wrote:
> On Fri, 12 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@amd.com>
>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
>> ---
>>  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 493998b42ec5..46f51ee459f6 100644
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -76,6 +76,12 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>      case PHYSDEVOP_unmap_pirq:
>>          break;
>>  
>> +    case PHYSDEVOP_setup_gsi:
>> +        if ( !is_hardware_domain(currd) )
>> +            return -EOPNOTSUPP;
>> +        ASSERT(!has_pirq(currd));
> 
> Do we really need this assert? I understand that the use case right now
> is for !has_pirq(currd) but in general it doesn't seem to me that
> PHYSDEVOP_setup_gsi and !has_pirq should be tied together.
Make sense, thanks for explanation, I will delete this in next version.

> 
> Aside from that, it looks fine.
> 
> 
>> +        break;
>> +
>>      case PHYSDEVOP_eoi:
>>      case PHYSDEVOP_irq_status_query:
>>      case PHYSDEVOP_get_free_pirq:
>> -- 
>> 2.34.1
>>

-- 
Best regards,
Jiqian Chen.