[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC XEN PATCH v2 3/3] tools: Add new function to get gsi from irq


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Mon, 4 Dec 2023 05:38:06 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C+jHOA5crJQE/M3R4WqciUpK6ckU/ukqoKfvEV+sg+4=; b=nVPx2iV2mZcFTMpzZNVntpbBjJNPjnjTFcvHHqibHaOW5ajUCGoXOXCffy7ZQbOAriaCO4Dwc65I71mpT3PhyfItAkFGCtps4OgTqVTYD8Gl04z+EGsk7/n7c1hzR0bJ/gmW7Jihofn4uwIudpc7JExnWCl6n7AEVdOVn+K+T143vkXqrZkuZNUi0H4SuU508VUaOH6XfYwcyq2JmVCUHc0VQszS05tOpCJiMUXmLpgrBDR2WbQhGuK4r9H7eM0u+0FHMm0s+ubThI/8qrcraQ1Exwsw+Pvf5bpKEryPxJCvLqUKtqR0GHj5FOXink0yYPxP9lT3N8dNMt8vglBpZg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jid3Qlpwx8EfBnEp/yJAmVtPKThOQj0ouyG/u2X4qA7L35yHxdyHFuJRD/Jhq6qF1CyO2xANfLCs347CuyrlHqVyAFvIbI48boE3GO9OBw4XLpgFX27X+DIEaMj+iefZ2g5HWWcf0/53nr6fS+53elNUBZ0fE+OOAQwrlKNCjrtFqkj6bHIiy5eXsNw8pIiocMg08Bt4O/uiOonORm6XmkdMkxAI68FVJAMMhowqiajq1r42bw9/V34tW/J2/mN+LOSGPqW0SltxbtOao7MmodmMZtUlpMY2emAUlVPbDHNMvMqUsGe9S3f+RTq3BYazOmDwIhXygNz65HwN9ZV0rg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Hildebrand, Stewart" <Stewart.Hildebrand@xxxxxxx>, "Deucher, Alexander" <Alexander.Deucher@xxxxxxx>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@xxxxxxx>, "Stabellini, Stefano" <stefano.stabellini@xxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "Huang, Honglei1" <Honglei1.Huang@xxxxxxx>, "Zhang, Julia" <Julia.Zhang@xxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Mon, 04 Dec 2023 05:38:23 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHaHsLpM7vOINXdREip1dGZpT1r3bCPz92AgAJv+QCAAAbDAIAAZb6AgAEdpwCAAGLbgIAFAhuA
  • Thread-topic: [RFC XEN PATCH v2 3/3] tools: Add new function to get gsi from irq

On 2023/12/1 17:03, Roger Pau Monné wrote:
> On Thu, Nov 30, 2023 at 07:09:12PM -0800, Stefano Stabellini wrote:
>> On Thu, 30 Nov 2023, Roger Pau Monné wrote:
>>> On Wed, Nov 29, 2023 at 08:02:40PM -0800, Stefano Stabellini wrote:
>>>> n Wed, 29 Nov 2023, Stefano Stabellini wrote:
>>>>> On Tue, 28 Nov 2023, Roger Pau Monné wrote:
>>>>>> On Fri, Nov 24, 2023 at 06:41:36PM +0800, Jiqian Chen wrote:
>>>>>>> In PVH dom0, it uses the linux local interrupt mechanism,
>>>>>>> when it allocs irq for a gsi, it is dynamic, and follow
>>>>>>> the principle of applying first, distributing first. And
>>>>>>> if you debug the kernel codes, you will find the irq
>>>>>>> number is alloced from small to large, but the applying
>>>>>>> gsi number is not, may gsi 38 comes before gsi 28, that
>>>>>>> causes the irq number is not equal with the gsi number.
>>>>>>> And when we passthrough a device, QEMU will use its gsi
>>>>>>> number to do mapping actions, see xen_pt_realize->
>>>>>>> xc_physdev_map_pirq, but the gsi number is got from file
>>>>>>> /sys/bus/pci/devices/xxxx:xx:xx.x/irq in current code,
>>>>>>> so it will fail when mapping.
>>>>>>> And in current codes, there is no method to translate
>>>>>>> irq to gsi for userspace.
>>>>>>
>>>>>> I think it would be cleaner to just introduce a new sysfs node that
>>>>>> contains the gsi if a device is using one (much like the irq sysfs
>>>>>> node)?
>>>>>>
>>>>>> Such ioctl to translate from IRQ to GSI has nothing to do with Xen, so
>>>>>> placing it in privcmd does seem quite strange to me.  I understand
>>>>>> that for passthrough we need the GSI, but such translation layer from
>>>>>> IRQ to GSI is all Linux internal, and it would be much simpler to just
>>>>>> expose the GSI in sysfs IMO.
>>>>>
>>>>> Maybe something to add to drivers/xen/sys-hypervisor.c in Linux.
>>>>> Juergen what do you think?
>>>>
>>>> Let me also add that privcmd.c is already a Linux specific interface.
>>>> Although it was born to be a Xen hypercall "proxy" in reality today we
>>>> have a few privcmd ioctls that don't translate into hypercalls. So I
>>>> don't think that adding IOCTL_PRIVCMD_GSI_FROM_IRQ would be a problem.
>>>
>>> Maybe not all ioctls translate to hypercalls (I guess you are
>>> referring to the IOCTL_PRIVCMD_RESTRICT ioctl), but they are specific
>>> Xen actions.  Getting the GSI used by a device has nothing do to with
>>> Xen.
>>>
>>> IMO drivers/xen/sys-hypervisor.c is also not appropriate, but I'm not
>>> the maintainer of any of those components.
>>>
>>> There's nothing Xen specific about fetching the GSI associated with a
>>> PCI device.  The fact that Xen needs it for passthrough is just a red
>>> herring, further cases where the GSI is needed might arise outside of
>>> Xen, and hence such node would better be placed in a generic
>>> location.  The right location should be /sys/bus/pci/devices/<sbdf>/gsi.
>>
>> That might be true but /sys/bus/pci/devices/<sbdf>/gsi is a non-Xen
>> generic interface and the maintainers of that portion of Linux code
>> might have a different opinion. We'll have to see.
> 
> Right, but before resorting to implement a Xen specific workaround
> let's attempt to do it the proper way :).
> 
> I cannot see why exposing the gsi on sysfs like that would be an
> issue.  There's a lot of resource information exposed on sysfs
> already, and it's a trivial node to implement.
Thanks for both of you' s suggestions. At present, it seems the result of 
discussion is that it needs to add a gsi sysfs. I will modify it in the next 
version and then add the corresponding maintainer to the review list.

> 
> Thanks, Roger.

-- 
Best regards,
Jiqian Chen.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.