From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH kvmtool] arm: Allow command line for firmware Date: Thu, 31 Jan 2019 13:48:16 +0000 Message-ID: <20190131134816.730a0b05@donnerap.cambridge.arm.com> References: <20190125154308.185131-1-andre.przywara@arm.com> <20190130182010.GE18558@fuggles.cambridge.arm.com> <20190131130715.d7ctomqoxw5e262f@kamzik.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Will Deacon , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org To: Andrew Jones Return-path: In-Reply-To: <20190131130715.d7ctomqoxw5e262f@kamzik.brq.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org On Thu, 31 Jan 2019 14:07:15 +0100 Andrew Jones wrote: > On Wed, Jan 30, 2019 at 06:20:10PM +0000, Will Deacon wrote: > > On Fri, Jan 25, 2019 at 03:43:08PM +0000, Andre Przywara wrote: > > > When loading a firmware instead of a kernel, we can still pass on > > > any *user-provided* command line, as /chosen/bootargs is a > > > generic device tree feature. We just need to make sure to not > > > pass our mangled-for-Linux version. > > > > > > This allows to run "firmware" images which make use of a command > > > line, still are not Linux kernels, like kvm-unit-tests. > > > > > > Signed-off-by: Andre Przywara > > > --- > > > Hi Will, > > > > > > this goes on top of Julien's firmware series (which did not yet > > > appear on kernel.org?) > > > This fixes an issue with some kvm-unit-tests support. [1] > > > > Does kvm-unit-tests break if we pass the modified command line? I'm > > wary of passing something different depending on whether the > > payload is firmware or kernel, because there's a pretty fine line > > between the two (and the firmware may even just forward the thing > > on to the kernel it loads). > > kvm-unit-tests assumes the user or unit test run scripts completely > control the kernel command line. The kernel command line is then > turned into the command line of the test's main() function, plus the > addition of the program name at argv[0]. The unit tests then parse > these command line parameters to determine what to do when testing. > If additional options are passed we need to teach the tests to ignore > them, and there's also risk that something passed in might > accidentally match a unit test parameter. Thanks Drew, was about to mention this as well. In general I find kvmtool a bit presumptuous in assuming that every guest kernel responses to Linux command line options. I see that kvmtool originated as a Linux debug tool, but running *BSD or Xen (with NV) doesn't sound too far off to me. There was this idea of introducing something like an --expert option, to tell kvmtool explicitly to omit any generated command line parameters. I then thought we could just piggy back on --firmware, which somewhat carries this kind of semantic anyway. And since we nuke every command line for --firmware right now, passing on the user provided one seems like the easiest. Those automated kvmtool features are somewhat dodgy anyway: for instance it drops the neat 9pfs forwaring when you specify a disk image, and you can't bring it back explicitly. Maybe --kernel and --firmware are just misleading names, it should be --linux and --kernel instead? But I guess we can't change this anymore. Cheers, Andre.