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
