On Fri, Feb 14, 2020 at 11:33:55AM +0100, David Hildenbrand wrote: > On 14.02.20 11:30, Andrew Jones wrote: > > On Fri, Feb 14, 2020 at 11:14:49AM +0100, David Hildenbrand wrote: > >> On 13.02.20 15:33, Andrew Jones wrote: > >>> Users may need to temporarily provide additional VMM parameters. > >>> The VMM_PARAMS environment variable provides a way to do that. > >>> We take care to make sure when executing ./run_tests.sh that > >>> the VMM_PARAMS parameters come last, allowing unittests.cfg > >>> parameters to be overridden. However, when running a command > >>> line like `$ARCH/run $TEST $PARAMS` we want $PARAMS to override > >>> $VMM_PARAMS, so we ensure that too. > >> > >> While reading this, I was wondering why not simply "$QEMU_PARAMS"? > > > > I'd like to slowly move away from assuming QEMU is the VMM. We > > already have support for kvmtool (to some degree) and I'd like > > to see that support increase. Also, maybe we'll eventually add > > support for a rust-vmm reference VMM to drive kvm-unit-tests. > > IOW, rather than add yet another QEMU named variable I'd like > > to start a trend of using VMM named variables. Actually, we > > could add VMM named alternatives for the QEMU named ones we have > > now and start using them in the scripts. We'd just need to remap > > the old names for backward compatibility early in the run. > > And we do expect other VMMs to eat the same set of parameters? If it's > QEMU specific, I think we should make this clear. It won't matter. The parameters are VMM specific. Whether or not where they show up on the command line has the same semantics as QEMU could be an issue, but what the parameters are is up to the user, and they should know which vmm they're currently using. kvmtool support isn't complete because the run scripts haven't yet provided a way for non-QEMU vmms to use the unittests.cfg files. Andre had some patches once, though. So maybe someday. Thanks, drew
