Re: [PATCH v2] xen/arm: fix build with HAS_PCI

["Roger Pau Monné" <roger.pau@citrix.com>]

On Tue, Jun 10, 2025 at 05:37:41PM +0100, Andrew Cooper wrote:
> On 10/06/2025 5:32 pm, Roger Pau Monné wrote:
> > On Tue, Jun 10, 2025 at 12:16:42PM -0400, Stewart Hildebrand wrote:
> >> On 6/10/25 11:51, Roger Pau Monné wrote:
> >>> On Tue, Jun 10, 2025 at 10:22:57AM -0400, Stewart Hildebrand wrote:
> >>>> In file included from ./include/xen/pci.h:72,
> >>>>                  from drivers/pci/pci.c:8:
> >>>> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
> >>>>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
> >>>>       |                                                  ^~~~~~~~
> >>>> cc1: all warnings being treated as errors
> >>>>
> >>>> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
> >>>> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
> >>> Sorry, it was my fault.
> >> No worries, it's pretty hard to catch when it can't be built without
> >> extra patches.
> >>
> >>> Would it make sense to introduce a Gitlab build that has HAS_PCI
> >>> enabled?  Or it won't build either without extra patches?
> >> It requires one extra patch ("xen/arm: pci: introduce PCI_PASSTHROUGH
> >> Kconfig option"):
> >>
> >> https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t
> >>
> >> It has an ack, although it needs a rebase and we would probably want to
> >> add HAS_VPCI_GUEST_SUPPORT now that upstream has that config too.
> > I think it would be helpful to be able to do a Gitlab build with
> > HAS_PCI enabled on ARM, otherwise it's inevitable for build issues to
> > creep in sadly.
> 
> This is what randconfig is for, and randconfig is active for arm64.
> 
> If something is preventing this configuration from being picked, that
> ought to be fixed.

But CONFIG_HAS_PCI is not user-selectable, it's one of those options
that (usually?) gets selected as part of the per-arch Kconfig.

> But, ARM already has a lot (too many) unconditional builds of specific
> feature combinations, and I don't think we want more.

Either it gets added to the default selection of ARM Kconfig options,
or exposed there using a user-selectable option that would then be
picked up by randconfig.

Thanks, Roger.