From: Jan Beulich <firstname.lastname@example.org> To: Julien Grall <email@example.com>, Rahul Singh <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, "Paul Durrant" <email@example.com>, "Andrew Cooper" <firstname.lastname@example.org>, "George Dunlap" <email@example.com>, "Ian Jackson" <firstname.lastname@example.org>, "Stefano Stabellini" <email@example.com>, "Wei Liu" <firstname.lastname@example.org>, "Daniel De Graaf" <email@example.com>, "Roger Pau Monné" <firstname.lastname@example.org> Subject: Re: [PATCH 2/2] xen/pci: Gate all MSI code in common code with CONFIG_HAS_PCI_MSI Date: Tue, 6 Apr 2021 17:25:12 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 06.04.2021 16:30, Julien Grall wrote: > Hi Roger, > > On 06/04/2021 15:13, Roger Pau Monné wrote: >> On Tue, Apr 06, 2021 at 12:39:11PM +0100, Rahul Singh wrote: >>> MSI support is not implemented for ARM architecture but it is enabled >>> for x86 architecture and referenced in common passthrough/pci.c code. >>> >>> Therefore introducing the new flag to gate the MSI code for ARM in >>> common code to avoid compilation error when HAS_PCI is enabled for ARM. >> >> Is such option really interesting long term? >> >> IIRC PCI Express mandates MSI support, at which point I don't see much >> value in being able to compile out the MSI support. > > I am pretty sure there are board out with PCI support but no MSI > support. Anyway, even if the spec may mandate it... > >> >> So while maybe helpful for Arm PCI efforts ATM, I'm not sure it >> warrants a Kconfig option, I would rather see Arm introduce dummy >> helpers for the missing functionality, even if unimplemented at the >> moment. > > ... from my understanding, most of (if not all) the MSI code is not very > useful on Arm when using the GICv3 ITS. > > The GICv3 ITS will do the isolation for you and therefore we should not > need to keep track of the state at the vPCI level. But that's then not "has PCI MSI" but "need to intercept PCI MSI accesses", i.e. I don't think the Kconfig option is correctly named. If a device with MSI support is used, you can't make that MSI support go away, after all. And of course I agree with the desire to have less #ifdef-ary here. Jan
next prev parent reply other threads:[~2021-04-06 15:25 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-06 11:39 [PATCH 0/2] xen/pci: Make PCI passthrough code non-x86 specific Rahul Singh 2021-04-06 11:39 ` [PATCH 1/2] xen/pci: Move PCI ATS code to common directory Rahul Singh 2021-04-06 15:16 ` Jan Beulich 2021-04-06 11:39 ` [PATCH 2/2] xen/pci: Gate all MSI code in common code with CONFIG_HAS_PCI_MSI Rahul Singh 2021-04-06 14:13 ` Roger Pau Monné 2021-04-06 14:30 ` Julien Grall 2021-04-06 14:59 ` Roger Pau Monné 2021-04-06 15:09 ` Julien Grall 2021-04-06 15:58 ` Roger Pau Monné 2021-04-07 17:52 ` Rahul Singh 2021-04-06 15:25 ` Jan Beulich [this message] 2021-04-07 18:06 ` Julien Grall 2021-04-08 6:00 ` Jan Beulich 2021-04-08 8:45 ` Rahul Singh
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/2] xen/pci: Gate all MSI code in common code with CONFIG_HAS_PCI_MSI' \ /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
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).