The commit 8fe743b5eba0 ("PCI: Add CONFIG_MMU dependency") restricts the
PCI base driver to depend on MMU.  While nommu UML _can_ implement PCI
drivers over PCI devices (e.g., virtio-pci), the current nommu UML
doesn't implement it.

But without PCI drivers kunit complains as config for kunit
(arch_uml.config) defines the dependency to PCI drivers.

This commit fixes the issue of this compile failures when building PCI
drivers with nommu UML.  In particular, the fix is to undefine the
constant PCI_IOBASE to be able to bypass pci_unmap_iospace() call.

When we will support PCI drivers for nommu UML, we will refactor this
code.

Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
---
 arch/um/include/asm/dma.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/um/include/asm/dma.h b/arch/um/include/asm/dma.h
index fdc53642c718..643d74555671 100644
--- a/arch/um/include/asm/dma.h
+++ b/arch/um/include/asm/dma.h
@@ -4,6 +4,19 @@
 
 #include <asm/io.h>
 
+/**
+ * now the PCI core driver depends on CONFIG_MMU in linus tree, nommu
+ * UML cannot build with PCI but without PCI kunit doesn't build due
+ * to the dependency to the CONFIG_VIRTIO_UML.
+ *
+ * This is a workaround to silence build failures on kunit, which is
+ * valid until nommu UML supports PCI drivers (e.g., virtio-pci) in a
+ * future.
+ */
+#ifndef CONFIG_MMU
+#undef PCI_IOBASE
+#endif
+
 extern unsigned long uml_physmem;
 
 #define MAX_DMA_ADDRESS (uml_physmem)
-- 
2.43.0

On Thu, 2025-09-18 at 16:39 +0900, Hajime Tazaki wrote:
> The commit 8fe743b5eba0 ("PCI: Add CONFIG_MMU dependency") restricts the
> PCI base driver to depend on MMU.  While nommu UML _can_ implement PCI
> drivers over PCI devices (e.g., virtio-pci), the current nommu UML
> doesn't implement it.
> 
> But without PCI drivers kunit complains as config for kunit
> (arch_uml.config) defines the dependency to PCI drivers.
> 
> This commit fixes the issue of this compile failures when building PCI
> drivers with nommu UML.  In particular, the fix is to undefine the
> constant PCI_IOBASE to be able to bypass pci_unmap_iospace() call.

This doesn't make a lot of sense to me. Why would we even want to build
PCI on NOMMU-UML if PCI in general is dependent on MMU now?

It's not like ARCH=um with PCI and NOMMU has any value even for testing
if such a configuration cannot exist in reality?

johannes

On Thu, 18 Sep 2025 17:30:22 +0900,
Johannes Berg wrote:
> 
> On Thu, 2025-09-18 at 16:39 +0900, Hajime Tazaki wrote:
> > The commit 8fe743b5eba0 ("PCI: Add CONFIG_MMU dependency") restricts the
> > PCI base driver to depend on MMU.  While nommu UML _can_ implement PCI
> > drivers over PCI devices (e.g., virtio-pci), the current nommu UML
> > doesn't implement it.
> > 
> > But without PCI drivers kunit complains as config for kunit
> > (arch_uml.config) defines the dependency to PCI drivers.
> > 
> > This commit fixes the issue of this compile failures when building PCI
> > drivers with nommu UML.  In particular, the fix is to undefine the
> > constant PCI_IOBASE to be able to bypass pci_unmap_iospace() call.
> 
> This doesn't make a lot of sense to me. Why would we even want to build
> PCI on NOMMU-UML if PCI in general is dependent on MMU now?
> 
> It's not like ARCH=um with PCI and NOMMU has any value even for testing
> if such a configuration cannot exist in reality?

totally understand your point.

now I see that we don't have to have this work around by using
--kconfig_add option to kunit.py.

# like --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n (in addition to
  --kconfig_add CONFIG_MMU=n).

so I'll drop this patch in the next version.

thanks,
-- Hajime

On Fri, 2025-09-19 at 09:03 +0900, Hajime Tazaki wrote:
> > This doesn't make a lot of sense to me. Why would we even want to build
> > PCI on NOMMU-UML if PCI in general is dependent on MMU now?
> > 
> > It's not like ARCH=um with PCI and NOMMU has any value even for testing
> > if such a configuration cannot exist in reality?
> 
> totally understand your point.
> 
> now I see that we don't have to have this work around by using
> --kconfig_add option to kunit.py.
> 
> # like --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n (in addition to
>   --kconfig_add CONFIG_MMU=n).

That's not what I mean. I think it should be made impossible to build
the broken code.

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?

johannes

On Fri, 19 Sep 2025 16:24:07 +0900,
Johannes Berg wrote:
> 
> On Fri, 2025-09-19 at 09:03 +0900, Hajime Tazaki wrote:
> > > This doesn't make a lot of sense to me. Why would we even want to build
> > > PCI on NOMMU-UML if PCI in general is dependent on MMU now?
> > > 
> > > It's not like ARCH=um with PCI and NOMMU has any value even for testing
> > > if such a configuration cannot exist in reality?
> > 
> > totally understand your point.
> > 
> > now I see that we don't have to have this work around by using
> > --kconfig_add option to kunit.py.
> > 
> > # like --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n (in addition to
> >   --kconfig_add CONFIG_MMU=n).
> 
> That's not what I mean. I think it should be made impossible to build
> the broken code.

okay.
# I think now I lost the point...

currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
so we cannot select it when CONFIG_MMU=n.

but it's different with kunit when using them via kunit.py config,

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.

and then execute make ARCH=um olddefconfig, which in turn enables
CONFIG_UML_PCI_OVER_VIRTIO.

if we append "--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n" to kunit.py,
it will overwrite the arch_uml.config.

# I don't know how kunit handles those appended CONFIG entries, though..

my goal is simple; to test !MMU code via kunit.
my original patch or the additional kconfig argument (--kconfig_add)
satisfies this goal.

> 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 ?

thanks,

-- Hajime

Hi Tazaki-san,

CC arnd

On Fri, 19 Sept 2025 at 11:32, Hajime Tazaki <thehajime@gmail.com> wrote:
> On Fri, 19 Sep 2025 16:24:07 +0900,
> Johannes Berg wrote:
> > On Fri, 2025-09-19 at 09:03 +0900, Hajime Tazaki wrote:
> > > > This doesn't make a lot of sense to me. Why would we even want to build
> > > > PCI on NOMMU-UML if PCI in general is dependent on MMU now?
> > > >
> > > > It's not like ARCH=um with PCI and NOMMU has any value even for testing
> > > > if such a configuration cannot exist in reality?
> > >
> > > totally understand your point.
> > >
> > > now I see that we don't have to have this work around by using
> > > --kconfig_add option to kunit.py.
> > >
> > > # like --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n (in addition to
> > >   --kconfig_add CONFIG_MMU=n).
> >
> > That's not what I mean. I think it should be made impossible to build
> > the broken code.
>
> okay.
> # I think now I lost the point...
>
> currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
> so we cannot select it when CONFIG_MMU=n.

That is a fairly recent change, see commit 8fe743b5eba0abfb ("PCI:
Add CONFIG_MMU dependency") in v6.16-rc1.  As this is not a "hard"
dependency, perhaps it should be reverted, iff you are willing to take
care of the casual breakage?

>
> but it's different with kunit when using them via kunit.py config,
>
> 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.
>
> and then execute make ARCH=um olddefconfig, which in turn enables
> CONFIG_UML_PCI_OVER_VIRTIO.
>
> if we append "--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n" to kunit.py,
> it will overwrite the arch_uml.config.
>
> # I don't know how kunit handles those appended CONFIG entries, though..
>
> my goal is simple; to test !MMU code via kunit.
> my original patch or the additional kconfig argument (--kconfig_add)
> satisfies this goal.
>
> > 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 ?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Tue, 2025-09-23 at 17:42 +0200, Geert Uytterhoeven wrote:
> > 
> > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
> > so we cannot select it when CONFIG_MMU=n.
> 
> That is a fairly recent change, see commit 8fe743b5eba0abfb ("PCI:
> Add CONFIG_MMU dependency") in v6.16-rc1.  As this is not a "hard"
> dependency, perhaps it should be reverted, iff you are willing to take
> care of the casual breakage?

Why though? UML with PCI can't really be a functional thing, only a
testing thing, and testing PCI on !MMU when that is actually impossible
in non-simulation is pointless?

johannes

Hello Geert, Johannes,

On Wed, 24 Sep 2025 02:13:47 +0900,
Johannes Berg wrote:
> 
> On Tue, 2025-09-23 at 17:42 +0200, Geert Uytterhoeven wrote:
> > > 
> > > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
> > > so we cannot select it when CONFIG_MMU=n.
> > 
> > That is a fairly recent change, see commit 8fe743b5eba0abfb ("PCI:
> > Add CONFIG_MMU dependency") in v6.16-rc1.  As this is not a "hard"
> > dependency, perhaps it should be reverted, iff you are willing to take
> > care of the casual breakage?
> 
> Why though? UML with PCI can't really be a functional thing, only a
> testing thing, and testing PCI on !MMU when that is actually impossible
> in non-simulation is pointless?

currently nommu UML doesn't come with using PCI except building under
kunit (ARCH=um), but I have in my mind to use it under !MMU
environment, so would be an option in the future.

and this series doesn't include PCI w/ !MMU.

so, I would propose the modification to revert the MMU dependency when
time has come.

btw, what do you mean by "hard" dependency in this context, Geert ? 

-- Hajime

On Wed, Sep 24, 2025, at 01:51, Hajime Tazaki wrote:
> On Wed, 24 Sep 2025 02:13:47 +0900, Johannes Berg wrote:
>> On Tue, 2025-09-23 at 17:42 +0200, Geert Uytterhoeven wrote:
>> > > 
>> > > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
>> > > so we cannot select it when CONFIG_MMU=n.
>> > 
>> > That is a fairly recent change, see commit 8fe743b5eba0abfb ("PCI:
>> > Add CONFIG_MMU dependency") in v6.16-rc1.  As this is not a "hard"
>> > dependency, perhaps it should be reverted, iff you are willing to take
>> > care of the casual breakage?
>> 
>> Why though? UML with PCI can't really be a functional thing, only a
>> testing thing, and testing PCI on !MMU when that is actually impossible
>> in non-simulation is pointless?
>
> currently nommu UML doesn't come with using PCI except building under
> kunit (ARCH=um), but I have in my mind to use it under !MMU
> environment, so would be an option in the future.
>
> and this series doesn't include PCI w/ !MMU.
>
> so, I would propose the modification to revert the MMU dependency when
> time has come.

The reason why it's currently disabled is that it was causing extra
work to fix build failures in random PCI drivers that individually
have a CONFIG_MMU dependency. Since we know that none of the NOMMU
boards we support uses PCI, this was an easy way to avoid work.

While there are still developers that care about NOMMU Linux
and test it on the platforms they use, the NOMMU build failures
usually end up in code that are irrelevant for their use cases,
so neither the platform owners nor the driver authors care deeply
about fixing that combination.

If you want to be able to use PCI drivers on UML-NOMMU,
you can probably use

config PCI
       depends on MMU || UML

so it will be ignored by the build bots on other architectures.
You'll still have to decide whether to fix driver code when
regressions in PCI drivers happen, add 'depends on !UML'
to individual drivers, or just live with randconfig failures.

      Arnd

Hi Hajime,

On Wed, 24 Sept 2025 at 01:51, Hajime Tazaki <thehajime@gmail.com> wrote:
> On Wed, 24 Sep 2025 02:13:47 +0900,
> Johannes Berg wrote:
> > On Tue, 2025-09-23 at 17:42 +0200, Geert Uytterhoeven wrote:
> > > > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
> > > > so we cannot select it when CONFIG_MMU=n.
> > >
> > > That is a fairly recent change, see commit 8fe743b5eba0abfb ("PCI:
> > > Add CONFIG_MMU dependency") in v6.16-rc1.  As this is not a "hard"
> > > dependency, perhaps it should be reverted, iff you are willing to take
> > > care of the casual breakage?
> >
> > Why though? UML with PCI can't really be a functional thing, only a
> > testing thing, and testing PCI on !MMU when that is actually impossible
> > in non-simulation is pointless?
>
> currently nommu UML doesn't come with using PCI except building under
> kunit (ARCH=um), but I have in my mind to use it under !MMU
> environment, so would be an option in the future.
>
> and this series doesn't include PCI w/ !MMU.
>
> so, I would propose the modification to revert the MMU dependency when
> time has come.
>
> btw, what do you mean by "hard" dependency in this context, Geert ?

I mean the PCI core does not really require an MMU, and PCI in-se
should work without it (e.g. on Coldfire MCF54xx).  Arnd added the
dependency to avoid having to deal with future build regressions.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

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

On Sat, 2025-09-20 at 08:46 +0900, Hajime Tazaki wrote:
> 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

That won't do anything since you elsewhere have "select UML_PCI"
independent of MMU.

> @@ -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

Right, but you also need that for UML_PCI_OVER_VFIO.

> 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

Well, OK, but that's fair - you did specifically override MMU=n, and
virtio-over-pci needs it.

> 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]).

I don't think (3) makes any sense at all, we should just _never_ do
that. !MMU is really here in UML for testing to support other
architectures that are !MMU, and since by today's definitions no other
architecture can have PCI without MMU, it makes no sense for UML to have
that (and complicate the PCI code unnecessarily, etc.)

I think it's entirely reasonable to have overriding CONFIG_MMU=n to also
necessitate overriding CONFIG_UML_PCI_OVER_VIRTIO, i.e. (1).

As to whether or not to add a specific config file, honestly I don't
really know or even care - you'd have to ask the people who actually
want to test !MMU.

johannes

On Mon, 22 Sep 2025 15:32:22 +0900,
Johannes Berg wrote:
> 
> On Sat, 2025-09-20 at 08:46 +0900, Hajime Tazaki wrote:
> > 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
> 
> That won't do anything since you elsewhere have "select UML_PCI"
> independent of MMU.

i see.

> > @@ -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
> 
> Right, but you also need that for UML_PCI_OVER_VFIO.

thanks, I understand too.

> > 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
> 
> Well, OK, but that's fair - you did specifically override MMU=n, and
> virtio-over-pci needs it.
> 
> > 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]).
> 
> I don't think (3) makes any sense at all, we should just _never_ do
> that. !MMU is really here in UML for testing to support other
> architectures that are !MMU, and since by today's definitions no other
> architecture can have PCI without MMU, it makes no sense for UML to have
> that (and complicate the PCI code unnecessarily, etc.)
> 
> I think it's entirely reasonable to have overriding CONFIG_MMU=n to also
> necessitate overriding CONFIG_UML_PCI_OVER_VIRTIO, i.e. (1).

okay, I'll go for this direction in the next series.

> As to whether or not to add a specific config file, honestly I don't
> really know or even care - you'd have to ask the people who actually
> want to test !MMU.

indeed, this will be the out of this series if needed.

-- Hajime

On Fri, 2025-09-19 at 11:38 +0200, Johannes Berg wrote:
> 
> 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.

No, that _is_ wrong, and it will end up in a circular dependency,
because for UML_PCI we currently do FORCE_PCI and then we have PCI and
HAVE_PCI and it all messes up ... Which is all correct right now.

That still seems reasonable (why give the choice of selecting PCI after
having selected VFIO/virtio PCI), but then with !MMU it can't work, so
the pieces there just need to depend on MMU.

johannes

On Fri, 2025-09-19 at 11:38 +0200, Johannes Berg wrote:
> 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.

And all the discussion is also true for UML_PCI_OVER_VFIO which also
selects UML_PCI.

johannes