Hey Ritesh, I just pulled some changes from Eric Biggers into xfstests-bld which has a start on adding riscv64 support to kvm-xfstests. So far, he's updated libaio to a newer upstream version (newer is relative; the "new" version was last updated six years ago :-) for better RiscV support, and he's added RiscV support to set_canonicalized_arch(). I'd recommend that you start with the latest upstream version of xfstests-bld, and then add support for powerpcle64 by adding support to find_kernel_to_use() in run=fstests/util/parse_opt_funcs, and set_cross_compile() and get_kernel_file_info() in run-fstests/util-arch, since those changes in the 2/2 patch series[1] were clearly correct. (And Eric, you should take a look at those changes[1] for RiscV support.) [1] https://lore.kernel.org/all/eb1f8f0fb0ff9a6358129a2a45bd0c88421ac669.1696965271.git.ritesh.list@xxxxxxxxx/ I'd also encourage you to add support for the new architectures in selftests/appliance, since that will exercise building a kernel for the foreign architecture using cross-compilation, and then using qemu-system-$ARCH from kvm-xfstests. (Yes, kvm-xfstests is starting to get very much misnamed; but kvm is easier to type, and autocompletes much more nicely than qemu-<tab>. The string "kvm" also is sprinkled all over the xfstests-bld scripts, and I'm not convinced it's worth changing. That being said, I've added a qemu-xfstests script which gets installed into the user's bin directory; we'll see if that is something people feel strongly about using the new name.) Finally, since have two separate efforts to add support for new architectures to xfstests-bld, might I prevail on you to keep some notes about what's needed to bootstrap a new architecture? That might be helpful for some future developer. Many thanks! - Ted
