Quoting Ted Ts'o:

Why does this important?  Because  the kernel developer will want to be running unit tests as well as building kernels that can be run under whatever architecture they are normally developing for (for example, an x86 kernel that can be run using kvm; or a arm64 kernel that gets run on an Android device by using the "fastboot" command).   So that means we don't want to be overwriting the object files and .config files for building the kernel for x86 when building the kunit kernel using the um arch.   For example, for ext4, my ideal workflow might go something like this:

<hack hack hack>
% ./tools/testing/kunit/kunit.py  run
<watch to see that unit tests succeed, and since most of the object files have already been built for the kunit kernel in be stored in the .kunit directory, this will be fast, since only the modified files will need to be recompiled>
% kbuild
<this is a script that builds an x86 kernel in /build/ext4-64 that is designed to be run under either kvm or in a GCE VM; since the kunit object files are stored in /build/ext4-kunit, the pre-existing files when building for x86_64 haven't been disturbed, so this build is fast as well>
% kvm-xfstests smoke
<this will run xfstests using the kernel plucked from /build/ext-64, using kvm>

The point is when I'm developing an ext4 feature, or reviewing and merging ext4 commits, I need to be able to maintain separate build trees and separate config files for ARCH=um as well as ARCH=x86_64, and if the ARCH=um are stored in the kernel sources, then building with O=... doesn't work:

<tytso@lambda> {/usr/projects/linux/kunit}   (kunit)
1084% make O=/build/test-dir
make[1]: Entering directory '/build/test-dir'
***
*** The source tree is not clean, please run 'make mrproper'
*** in /usr/projects/linux/kunit
***

The full discussion can be found here: https://groups.google.com/d/msg/kunit-dev/QmA27YEgEgI/hvS1kiz2CwAJ