runqemu adds network configuration parameters to the kernel
command line to configure guest networking. This works only
for the images that run with external kernel using qemu -kernel
parameter. It doesn't work for the images that use bootloader
to boot kernel as -kernel parameter is not used and network
configuration is not possible to get.

Added host and guest ip addresses and netmask of tap link
to the runqemu output. This should allow external programs
that execute runqemu to get network configuration.

[YOCTO #10833]

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This can fix a problem:
IMAGE_FSTYPES += "iso"
$ bitbake core-image-minimal
$ runqemu qemux86

It may boot core-image-minimal-initramfs rather than core-image-minimal, this
is not what we want usually. This patch makes it avoid booting ramfs when there
are other choices, or when it is specified, for example, "runqemu qemux86 ramfs"

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Fixed:
$ runqemu -h
runqemu - INFO - Assuming MACHINE = -h
runqemu - INFO - Running MACHINE=-h bitbake -e...
[snip]
Exception: FSTYPE is NULL!

[YOCTO #10941]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Fixed:
$ runqemu core-image-minimal
[snip]
Exception: FSTYPE is NULL!
[snip]

Get DEPLOY_DIR_IMAGE from "bitbake -e" to make it work.

[YOCTO #10471]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Presently, runqemu sets up rootfs as part of network setup.
In case there is no network desired we will end up without rootfs
as well.
This patch sets up network and rootfs independently.
It is also possible to bypass setup of rootfs if QB_ROOTFS is set to "none".

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Currently runqemu hardcodes the "ip=" kernel boot parameter
when configuring QEMU to use tap or slirp networking. This makes
the guest system to have a network interface pre-configured
by kernel and causes systemd to fail renaming the interface
to whatever pleases it:

  Feb 21 10:10:20 intel-corei7-64 systemd-udevd[201]: Error changing
      net interface name 'eth0' to 'enp0s3': Device or resource busy,

Always append user input for kernel boot params after the ones
added by the script. This way user input has priority over runqemu's
default params.

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

We always wants ttyS0 and ttyS1 in qemu machines (see SERIAL_CONSOLES),
if not serial or serialtcp options was specified only ttyS0 is created
and sysvinit shows an error trying to enable ttyS1:

     INIT: Id "S1" respawning too fast: disabled for 5 minutes

[YOCTO #10491]

(From OE-Core rev: 3a0efbbe6bb5a7f0fb3df0f6052b11e56788405f)

Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In the simplest case, "runqemu qemux86 <some-image> qcow2 ovmf" for an
EFI-enabled image in the qcow2 format will locate the ovmf.qcow2
firmware file deployed by the ovmf recipe in the image deploy
directory, override the graphics hardware with "-vga std" because that
is all that OVMF supports, and boot with UEFI enabled.

ovmf is not built by default. Either do it explicitly ("bitbake ovmf")
or make it a part of the normal build
("MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = ' ovmf'").

The firmware file is activated as a flash drive instead of using the
qemu BIOS parameters, because that is the recommended method
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47) as it
allows storing UEFI variables in the file.

Instead of just "ovmf", a full path to an existing file can also be
used, just as with the rootfs. That may be useful when making a
permanent copy of the virtual machine data files.

It is possible to specify "ovmf*" parameters more than once, then
each parameter creates a separate flash drive. This way it is possible
to use separate flash drives for firmware code and variables:
$ runqemu qemux86 <some-image> qcow2 ovmf.code ovmf.vars"

Note that rebuilding ovmf will overwrite the ovmf.vars.qcow2 file in
the image deploy directory. So when the goal is to update the firmware
while keeping variables, make a copy of the variable file and use
that:
$ mkdir my-machine
$ cp tmp/deploy/images/qemux86/ovmf.vars.qcow2 my-machine/
$ runqemu qemux86 <some-image> qcow2 ovmf.code my-machine/ovmf.vars.qcow2

When Secure Boot was enabled in ovmf, one can pick that instead of
the non-Secure-Boot enabled ovmf.code:
$ runqemu qemux86 <some-image> qcow2 ovmf.secboot.code my-machine/ovmf.vars.qcow2

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>

The magic detection of the rootfs parameter only worked for image
recipes which embedd the "image" string in the middle, as in
"core-image-minimal".

Sometimes it is more natural to call an image "something-image". To
get such an image detected by runqemu, "-image" at the end of a
parameter must also cause that parameter to be treated as the rootfs
parameter.

Inside the image directory, "something-image" has an -<arch> suffix
and thus no change is needed for those usages of
re.search('-image-'). However, while at it also enhance those string
searches a bit (no need for re; any()+map() a bit closer to the
intended logic).

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>

'arg' isn't defined, the right name there is 'p'.

This fixes a rather obscure error message when that code path
ends up being taken:

$ runqemu some/existing-file-name
runqemu - ERROR - name 'arg' is not defined
runqemu - ERROR - Try 'runqemu help' on how to use it

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>