thanks Johannes, I think I got a clearer view than before.
I guess Kconfig does the right thing.
And Kunit does the right too but an additional job which Kunit does
prevents run tests w/ !MMU.
> > CONIFG_MMU=n
> >
> > via --kconfig_add CONFIG_MMU=n.
>
> Sure. But that should disable CONFIG_UML_PCI_OVER_VIRTIO, and it doesn't
> now.
Kconfig (via kunit.py config) disables CONFIG_UML_PCI_OVER_VIRTIO
correctly.
But after that, Kunit does the additional job, validate_config() (in
kunit_kernel.py), which checks the configs (arch_uml.config +
--kconfig_add) is a subset of the final result of .config.
When I applied a patch below:
diff --git a/arch/um/drivers/Kconfig b/arch/um/drivers/Kconfig
index 6a0354ca032f..04025207a077 100644
--- a/arch/um/drivers/Kconfig
+++ b/arch/um/drivers/Kconfig
@@ -159,6 +159,7 @@ config UML_RTC
config UML_PCI
bool
+ depends on MMU
select FORCE_PCI
select IRQ_MSI_LIB
select UML_IOMEM_EMULATION
@@ -170,6 +171,7 @@ config UML_PCI_OVER_VIRTIO
bool "Enable PCI over VIRTIO device simulation"
# in theory, just VIRTIO is enough, but that causes recursion
depends on VIRTIO_UML
+ depends on MMU
select UML_PCI
and do
./tools/testing/kunit/kunit.py config --kconfig_add CONFIG_MMU=n
the validation currently gives the following error:
ERROR:root:Not all Kconfig options selected in kunitconfig were in the
generated .config.
This is probably due to unsatisfied dependencies.
Missing: CONFIG_UML_PCI_OVER_VIRTIO=y
Note: many Kconfig options aren't available on UML. You can try
running on a different architecture with something like
"--arch=x86_64".
so, if I give an additional --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n
to the command line, the validation passes, because the configs
(arch_uml.config + --kconfig_add) becomes the subset of the final
result.
what I can handle this would be either of them:
1) use --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n when using kunit w/
!MMU, and drop this patch from the series (no modification to the tree)
2) prepare a different file for !MMU & ARCH=um testing (e.g.,
arch_uml_nommu.config), and add an option to kunit.py to switch MMU
or !MMU
3) implement virtio-pci for !MMU and propose to remove the restriction
of CONFIG_PCI depends on CONFIG_MMU.
2) will be removed when 3) is done so, I'm hesitating to propose a
patch used by whole tree.
so, I think 1) is (not the best but) a reasonable solution, with a
note in nommu-uml specific document (i.e., [PATCH 12/13]).
Let me know what you think.
-- Hajime
On Fri, 19 Sep 2025 18:38:03 +0900,
Johannes Berg wrote:
>
> On Fri, 2025-09-19 at 18:32 +0900, Hajime Tazaki wrote:
> > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
>
> Right.
>
> > so we cannot select it when CONFIG_MMU=n.
>
> Actually, I believe that's not true, I think it *can* select something
> even if you override the 'depends on' it has, it just causes a warning
> in Kconfig.
>
> But I don't think PCI is even selected, UML_PCI is selected, and then
> that selects PCI_MSI which should really only be reachable when PCI is
> enabled, so this perhaps does nothing? Not sure ...
>
> > but it's different with kunit when using them via kunit.py config,
>
> It really isn't, you just don't see everything because kunit.py hides
> the build from you.
>
> > it first adds
> >
> > CONFIG_VIRTIO_UML=y
> > CONFIG_UML_PCI_OVER_VIRTIO=y
> >
> > via tools/testing/kunit/configs/arch_uml.config, and then add
> >
> > CONIFG_MMU=n
> >
> > via --kconfig_add CONFIG_MMU=n.
>
> Sure. But that should disable CONFIG_UML_PCI_OVER_VIRTIO, and it doesn't
> now.
>
> > and then execute make ARCH=um olddefconfig, which in turn enables
> > CONFIG_UML_PCI_OVER_VIRTIO.
>
> Keeps it, let's say.
>
> > if we append "--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n" to kunit.py,
> > it will overwrite the arch_uml.config.
>
> Yeah but that being required doesn't make sense - the Kconfig should
> express the correct dependencies.
>
> > # I don't know how kunit handles those appended CONFIG entries, though..
>
> It just puts them into the file and runs oldconfig, I guess?
>
> > my goal is simple; to test !MMU code via kunit.
>
> Sure.
>
> > my original patch or the additional kconfig argument (--kconfig_add)
> > satisfies this goal.
>
> Sure. But both are the wrong solution, as I said, the Kconfig should
> express the correct dependencies.
>
> > > The problem is probably UML_PCI_OVER_VIRTIO selecting UML_PCI selecting
> > > various PCI code, but nothing depends on PCI in the first place. Which
> > > it should, then?
> >
> > I don't understand the 'nothing depends on PCI...' part. care to
> > elaborate ?
>
> See above, I think?
>
> My gut feeling is that UML_PCI_OVER_VIRTIO should depend on PCI but I
> don't know if that then doesn't end up in some kind of circular
> dependency.
>
> johannes
