From: Rahul Singh <Rahul.Singh@arm.com>
To: Julien Grall <julien@xen.org>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
"Bertrand Marquis" <Bertrand.Marquis@arm.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>,
"George Dunlap" <george.dunlap@citrix.com>,
"Ian Jackson" <iwj@xenproject.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Paul Durrant" <paul@xen.org>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH v2] xen/pci: Refactor PCI MSI interrupts related code
Date: Mon, 19 Apr 2021 07:16:52 +0000 [thread overview]
Message-ID: <AD2BC1CD-74AF-48FF-8B42-2853C0E7A7BE@arm.com> (raw)
In-Reply-To: <788665ad-9815-e3e9-2d5a-851b35c566d0@xen.org>
Hi All,
> On 15 Apr 2021, at 2:31 pm, Julien Grall <julien@xen.org> wrote:
>
> Hi Roger,
>
> On 15/04/2021 14:26, Roger Pau Monné wrote:
>> 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).
>
> Well... x86-specific devices yes. We don't know in what form MSI will be added on for other arch-specific devices.
>
> 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.
>
> My preference would be to comment in the commit message (although, there is no promise they will ever get re-used). We can then modify the #ifdef once we introduce any use.
>
Thanks you everyone for reviewing the code. I will summarise what I have understood from all the comments
and what I will be doing for the next version of the patch. Please let me know your view on this.
1. Create a separate non-arch specific file "msi-intercept.c" for the below newly introduced function and
compile that file if CONFIG_PCI_MSI_INTERCEPT is enabled.CONFIG_PCI_MSI_INTERCEPT will be
enabled for x86 by default. Also Mention in the commit message that these function will be needed for Xen to
support MSI interrupt within XEN.
pdev_msi_initi(..)
pdev_msi_deiniti(..)
pdev_dump_msi(..),
pdev_msix_assign(..)
2. Create separate patch for iommu_update_ire_from_msi() related code. There are two suggestion please help me which one to choose.
- Move the iommu_update_ire_from_msi() function to asm-x86/iommu.h and also move the hook from iommu_ops under CONFIG_X86.
- Implement a more generic function "arch_register_msi()"). This could call iommu_update_ire_from_msi() on x86 and the
ITS related code once implemented on Arm. Introduce the new Kconfig CONFIG_HAS_IOMMU_INTERRUPT_REMAP for this option.
3. As per the discussion I will gate the struct vpci_msi {..} and struct vpci_msix{..} using CONFIG_PCI_MSI_INTERCEPT so that
they will not will be accessible on ARM.
Regards,
Rahul
> Cheers,
>
> --
> Julien Grall
next prev parent reply other threads:[~2021-04-19 7:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 16:00 [PATCH v2] xen/pci: Refactor PCI MSI interrupts related code Rahul Singh
2021-04-12 10:49 ` Roger Pau Monné
2021-04-12 11:28 ` Jan Beulich
2021-04-12 18:26 ` Rahul Singh
2021-04-12 16:28 ` Rahul Singh
2021-04-13 17:12 ` Julien Grall
2021-04-14 7:08 ` Jan Beulich
2021-04-14 8:28 ` Roger Pau Monné
2021-04-14 8:47 ` Jan Beulich
2021-04-14 8:28 ` Julien Grall
2021-04-14 8:05 ` Roger Pau Monné
2021-04-14 8:49 ` Julien Grall
2021-04-15 13:26 ` Roger Pau Monné
2021-04-15 13:31 ` Julien Grall
2021-04-19 7:16 ` Rahul Singh [this message]
2021-04-19 8:40 ` Roger Pau Monné
2021-04-19 11:16 ` Jan Beulich
2021-04-19 11:54 ` Julien Grall
2021-04-19 12:33 ` Jan Beulich
2021-04-20 13:45 ` Rahul Singh
2021-04-20 15:36 ` Jan Beulich
2021-04-21 8:07 ` Rahul Singh
2021-04-21 8:16 ` Roger Pau Monné
2021-04-21 9:15 ` Rahul Singh
2021-04-21 9:33 ` Jan Beulich
2021-04-21 11:55 ` Rahul Singh
2021-04-21 9:32 ` Jan Beulich
2021-04-21 9:01 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AD2BC1CD-74AF-48FF-8B42-2853C0E7A7BE@arm.com \
--to=rahul.singh@arm.com \
--cc=Bertrand.Marquis@arm.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).