Re: [PATCH kvmtool] arm: Allow command line for firmware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 31 Jan 2019 14:07:15 +0100
Andrew Jones <drjones@xxxxxxxxxx> 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 <andre.przywara@xxxxxxx>
> > > ---
> > > 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.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux