We need this kernel command parameter so that when we start a ramfs
image, we can actually get some output. Although we can make this
happen by specifying the 'bootparams' for the 'runqemu' command, it's
better to make this the default behaviour.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Support the sitauation where a user could have another VM running
which uses tap devices. To prevent runqemu from trying to use the
same tap device, runqemu will skip using a tap device if it finds
a filename tapX.skip within its lock directory.

This fixes [YOCTO #5815]

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Set in accordance with qemu machines configs.

Fixes [YOCTO #5817].

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Now that the tune for qemux86-64 changed to core2-64 we need to
tell the emulator to use a proper CPU model. With the default setting
of qemu64 we'll get things like:

root@qemux86-64:~# smart --help
traps: python[758] trap invalid opcode ip:7f2af01f6be7 sp:7fff49466ef0 error:0 in strop.so[7f2af01f5000+6000]
Illegal instruction

If the tune for qemux86 changes, that needs to be updated too.

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The default slirp address for the NFS server is 10.0.2.2.  If not
using a tap interface this address must be used or the target system
cannot connect properly.  Also the ip=... kernel arguments need to be
set to dhcp when using slirp or the root NFS will not get setup
properly.

The call to cleanup() results in a routine which is not defined when
setting up the NFS because it is called before acquire() for the
locking of the tap interfaces, the solution being to simply not call
cleanup() that early.

When using slirp, kvm should not execute the vhost net checks because
the vhost net will not be configure or used.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

This new version correctly handles the 64bit ext3 / ext4 issues we
were seeing with the older unfs-server which did not handle 64bit file
systems correctly, producing the duplicate cookies.

[YOCTO #5639]

Signed-off-by: Saul Wold <sgw@linux.intel.com>

At the moment, the user cannot to set -vga other then vmware
(because "vmware" is set by default); and the first argument
in qemuparams has higher precedence.

Signed-off-by: Valentin Popa <valentin.popa@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

The following commit, 6ccd4d6, increased the RAM size for qemu machines
to 256MB due to some smart sanity tests failing on autobuilder because
more memory was needed.

Unfortunately this leads to various, potentially dangerous, issues like
the one observed during sudoku-savant project compilation:

collect: relinking
collect2: error: '_ZNK6sudoku5ClearINS_6SquareEEclERS1_' was assigned to
'board.rpo', but was not defined during recompilation, or vice versa
board.o:(.rodata+0x8): undefined reference to
`sudoku::Clear<sudoku::Square>::operator()(sudoku::Square&) const'
board.o:(.rodata+0x20): undefined reference to
`sudoku::Clear<sudoku::Sequence>::operator()(sudoku::Sequence&) const'
board.o:(.rodata+0x34): undefined reference to `typeinfo for
sudoku::Action<sudoku::Sequence>'
...AND THE LIST CONTINUES...
collect2: error: ld returned 1 exit status
make: *** [sudoku-savant] Error 1

After some tests, I found that the maximum amount of memory needed for
sudoku to compile properly is 146MB(!?!).

My attempts to create a simpler test case (using templates), in order to
replicate and isolate the issue failed. All the tests compiled just
fine.

So, my guess is that this problem is certainly memory related but the
cause might be hidden in any of the following: qemu versatile hw model,
in the kernel or, highly unlikely but not impossible, the toolchain
itself. The reason I don't really think the cause is in the toolchain is
the fact that the compilation completes just fine for 128MB on qemuarm but
also on other qemu machines (with 256MB of memory).

Since this issue might need lots of time to have a proper fix, I'll revert back
to using 128MB for qemuarm for the time being.

[YOCTO #5133]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Set memory size to 256M for qemuarm, qemux86, qemux86-64, qemumips,
qemumips64, and qemuppc.

This allows the smart automated tests to run on machines with a GUI
environment (such as Sato) running at the same time, for which 128M is
too limiting. Setting this in runqemu allows users manually using
runqemu to avoid the same out-of-memory issues under similar conditions
using smart, on-target compilation or other uses.

Fixes [YOCTO #5045].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

We should provide the user more information if a preconfigured tap
is used. This is because the user might have manually set up the tap
interface to be used by other qemu binaries.

So at a minimum, we should let the user know how to make runqemu skip
that tap interface.

[YOCTO #5047]

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>