[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] xen/pci: Refactor PCI MSI interrupts related code
- To: Julien Grall <julien@xxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 15 Apr 2021 15:26:02 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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-SenderADCheck; bh=d1l51CG56aHNvtKJYuTpSQmSe+EouQr16Sczlo1cgeY=; b=VAj3RREV//tpbEc6+/xzmuzwkCckS8JLI58G+7ttJPqyspiAmCF2jO8xa0x486976qPhaeBu9WXa7fUC/W98iPfaPAM8ch1s2ughT1P6lqa9LxZ9S0zO47bZzP20WYrT8cvwsRrGc8y0WqOKYCsSu+DIa1lDEG8dsOMD+p2aWzvi0RNhSjYjYT1oF/jTV4u5ALnUSVRmiru287tk75sa6lypg1WvF/bQy1ONMFBR40h0XshOLFl5yVa25YvWvjKLnfmnlamR7FAnrqrXNqlcjEsYjMgOGT63RFGgLbTJ0jCno/YHYozrKal2+d2tVXBEin7S65s9L2/aUUojeDk5VA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zp/RkU+Qd99NiXMmR5DdB8DEBOJKEYj3BAcIAUD3T2eiKEwcEnpT9MwGCxQ7ZZG8N/vsYs9tN7J+3cUcYDmDmmAKO74mYpg0xVpefIyFzBCzzsadmil1ZJ9Ozf1qlcOFyoUxxGO8l/nQZlBoBJK7n8aMjcxm5NaChHSxDmJ9WRkWawer5q2S3nb/i5NSZpX5Wt/XN5eYIF4v/MSebpwtWsLR7nLRFoSS6PYvhhnN+mLwfBD5ziUeItd7Z4uIbOsJul4mGGrVTbn8EiHM9PlL3fT9HkZjUbxffqsKV02EmR8uQd3I+aUmwxbjPRufonXU96QF5KJvMGchV1t5F1lmlw==
- Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Rahul Singh <rahul.singh@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <bertrand.marquis@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
- Delivery-date: Thu, 15 Apr 2021 13:26:19 +0000
- Ironport-hdrordr: A9a23:LwTNw6NyUuMnNMBcT3Hw55DYdL4zR+YMi2QD/3taDTRIb82VkN 2vlvwH1RnyzA0cQm0khMroAsa9aFvm39pQ7ZMKNbmvGDPntmyhMZ144eLZrwHIMxbVstRQ3a IIScVDIfXtEFl3itv76gGkE9AmhOKK6rysmP229RZQZCtBApsQiDtRIACdD0FwWU1qBYAhEo Cd+8pAoFObCA4qR+68AWQIWPWGmsbCk4jobQVDKxks7gSPij3A0s+GLzGz2BACXzRThYoz6G StqX2D2oyPkdGejiXd2Wja8ohMlLLapOdrKcSQhqEuW1fRoymyYoAJYczmgBkUp6WV5E8ugJ 3wpX4bTrhOwlfwWk3wnhf3wQnn118Vmg/f4HuVm2Hqr8C8ZB9SMbs5uatjfhHU61UtsbhHuc ohtQLp1OskMTr6kCvw/NTOXR1x/3DE2UYKquIPk2dZFbIXdb45l/1vwGpuDJwCECjmgbpXdt VGMce03oczTXqqK1rdvmVp3eW2WGUyEhqsUiE5y7Ko+gkTs3Zjw0QCwssD2l8G6ZImUpFBo9 /JK6Jyidh1P4MrRJM4IN1Ebdq8C2TLTx6JGGWOIW7/HKVCH37WsZb47Jg8+enCQu1G8LIC3L D6FH9Iv287fEzjTeeU2odQzxzLSGKhGRzw18B3/fFCy/3BbYuuFRfGZEElksOmrflaKNbcQe yPNJVfBOKmBXfyGLxOwxb1V/BpWDgjefxQnux+d0OFo8rNJIGvnPfcauzvKL3kFithdXj4Bl cFQTjvNORN5k2mQRbD8VrsckKoXna60YN7EaDc8eRW4pMKLJdwvg8cjkn8xszjE0wGjoUGOG 9FZJ/3mKKyome7uUzS6X9yBxZbBkFJpJHpU3ZAox42I1r5GIxz/+m3SCR35j+qNxV/R8TZHE p0vFJs45+6KJSW2GQEB8+4NHmZy18evmiDQZtZuqDr37aqRroISrIdHIBhHwTCEBJ43Sxwrn 1YVQMCTkjDUhX0iauki5QQLPrFd8Z1hTqqJcI8kwOdiWys4eUUAlcLVT+nVsCaxSw0QSBPu1 F3+6gDxIablS2XMms5iuQgOFhqYGCaaYg2SzitVcFxoPTGaQtwRWCFiXi/hwsocmTnzUkUm1 fsNDaZY/3NH1pbtE1Jy6qCyiIGSkytO2ZLLlxqu4x0EmrL/kx+1uKGfYKf+WqcYFlq+JBXDB j1JR8pZi9+zdG+0xCY3AuYHXI935M0I6j2F7I4aYze3XurNayFnawLBOVv4Z5gLdzi29V7F9 63SkuwFnfVGukp0wuaqjIZIyFysmAjiu6t9xv/7mS0tURPd8b6ERBDffU8LN6d5WS/GKrN/5 V9kN4vvey/dk/2ccWLzKnLbzhFbjPfyFTGO90AmNRxh+YVsrA2IrzwFR3v/1tD1A8lLMj1mF gFKZ4LqIzpC8tKRYgqZyld/lAVj9yBI0sgjxzuDoYFDCQQpk6eG+nM3qHBprUuCHCQvQfcOV GQ9CtG4vfONhHzooIyOuYVIW5MblI752kn1OSed5fIAAHCTZAIwHOKdlu8eqRaUq6LBPE5qQ t7+ciBm6uyezDj0A7d+Rt9LaQmyRfrfeqCRCaNE/VP6dq0JBClhbar+te6iHPPcgSAAn5ozL FtRAg3dcRMij4rkY0x3GyTc8XM0z0YumobxypmmF7r0pWh+0HBEyh9QFTkvqk=
- Ironport-sdr: qO2iktrbtbX4Ze2MBoRpbQzfwPLYUuZJOImC6T4AnbzCTQkQzgurixXKYOCM0cbk0qkveB0Zy+ 3VuVBAUfAlMGMMXW+7r9fDIUv0/vX/ZG+nTBuCCuEG+1sWsnF/dREdfz+x2XWAMvfFsph36EbS nHp6Vl10xcRxJLf5UCC1NA1nXtqTdMO/Gb+unWpxh+mecKgIZsK0sQDWobhzYBv+FRe+XIFUFa xtXWXHLrH3BXRRC0Qxsjqg5p9ioh5nOW/FOsKvrrNc1LpJseWu874J0vQrpWmbPp5N9G1NqLvM auQ=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Apr 14, 2021 at 09:49:37AM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 14/04/2021 09:05, Roger Pau Monné wrote:
> > On Tue, Apr 13, 2021 at 06:12:10PM +0100, Julien Grall wrote:
> > > Hi Roger,
> > >
> > > On 12/04/2021 11:49, Roger Pau Monné wrote:
> > > > On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
> > > > > diff --git a/xen/drivers/passthrough/pci.c
> > > > > b/xen/drivers/passthrough/pci.c
> > > > > index 705137f8be..1b473502a1 100644
> > > > > --- a/xen/drivers/passthrough/pci.c
> > > > > +++ b/xen/drivers/passthrough/pci.c
> > > > > @@ -1303,12 +1279,15 @@ static int __init setup_dump_pcidevs(void)
> > > > > }
> > > > > __initcall(setup_dump_pcidevs);
> > > > > +
> > > > > +#ifdef CONFIG_PCI_MSI_INTERCEPT
> > > > > int iommu_update_ire_from_msi(
> > > > > struct msi_desc *msi_desc, struct msi_msg *msg)
> > > > > {
> > > > > return iommu_intremap
> > > > > ? iommu_call(&iommu_ops, update_ire_from_msi, msi_desc,
> > > > > msg) : 0;
> > > > > }
> > > > > +#endif
> > > >
> > > > This is not exactly related to MSI intercepts, the IOMMU interrupt
> > > > remapping table will also be used for interrupt entries for devices
> > > > being used by Xen directly, where no intercept is required.
> > >
> > > On Arm, this is not tie to the IOMMU. Instead, this handled is a separate
> > > MSI controller (such as the ITS).
> > >
> > > >
> > > > And then you also want to gate the hook from iommu_ops itself with
> > > > CONFIG_PCI_MSI_INTERCEPT, if we want to got this route.
> > >
> > >
> > > All the callers are in the x86 code. So how about moving the function in
> > > an
> > > x86 specific file?
> >
> > Yes, that seems fine. Just place it in asm-x86/iommu.h. I wonder why
> > update_ire_from_msi wasn't moved when the rest of the x86 specific
> > functions where moved there.
>
> I am guessing it is because the function was protected by CONFIG_HAS_PCI
> rather than CONFIG_X86. So it was deferred until another arch enables
> CONFIG_HAS_PCI (it is easier to know what code should be moved).
>
> > Was there an aim to use that in other
> > arches?
>
> In the future we may need to use MSIs in Xen (IIRC some SMMUs only support
> MSI interrupt).
Then I think some of the bits that are moved from
xen/drivers/passthrough/pci.c (alloc_pci_msi, free_pci_msi and
dump_pci_msi) need to be protected by a Kconfig option different than
CONFIG_PCI_MSI_INTERCEPT, as those are not related to MSI interception,
but to MSI handling in general (ie: Xen devices using MSI need
those). The same with the msi_list and msix fields of pci_dev, those
are not only used for MSI interception.
Or at least might be worth mentioning that the functions will be
needed for Xen to be able to use MSI interrupts itself, even if not
for interception purposes.
Thanks, Roger.
|