kvm tools: implement "help xxx" command

'kvm run --help' works fine but 'kvm help run' shows nothing,
this patch implements it.

Acked-by: Prasad Joshi <prasadjoshi124@gmail.com>
Signed-off-by: WANG

kvm tools: implement "help xxx" command

'kvm run --help' works fine but 'kvm help run' shows nothing,
this patch implements it.

Acked-by: Prasad Joshi <prasadjoshi124@gmail.com>
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Default guest cpu count to host cpu count

If user haven't specified cpu count for the guest, use
the amount of online cpus on the host.

Tested-by: Asias He <asias.hejun@gmail.com>
Signed

kvm tools: Default guest cpu count to host cpu count

If user haven't specified cpu count for the guest, use
the amount of online cpus on the host.

Tested-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Exit properly on SMP guests

When shutting down SMP guests only VCPU #0 will receive
a KVM_EXIT_SHUTDOWN. Waiting for all VCPU threads to exit
causes them to hang.

Instead, notify all VCP

kvm tools: Exit properly on SMP guests

When shutting down SMP guests only VCPU #0 will receive
a KVM_EXIT_SHUTDOWN. Waiting for all VCPU threads to exit
causes them to hang.

Instead, notify all VCPU threads once VCPU #0 thread is terminated
so they could also stop properly.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Prefix error() and friends helpers with pr_

To look more familiar with kernel functions.

Suggested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Ack

kvm tools: Prefix error() and friends helpers with pr_

To look more familiar with kernel functions.

Suggested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Make host_ram_size() more robust

This patch fixes cryptic "out of memory" errors on hosts where sysconf() fails
by defaulting to MIN_RAM_SIZE_MB.

Reported-by: <born2befrag@gmail.com>
Sig

kvm tools: Make host_ram_size() more robust

This patch fixes cryptic "out of memory" errors on hosts where sysconf() fails
by defaulting to MIN_RAM_SIZE_MB.

Reported-by: <born2befrag@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Tune the command-line option

With this patch we can have
-c --cpus
-m --mem
-d --disk
-k --kernel
-i --initrd
which is more consistent and easy to remember.

The patch also frees up

kvm tools: Tune the command-line option

With this patch we can have
-c --cpus
-m --mem
-d --disk
-k --kernel
-i --initrd
which is more consistent and easy to remember.

The patch also frees up -s, -g option.

Ingo suggestied
'''
The debug options should probably be concentrated under a --debug option
anyway, to allow things like:

--debug single-step,ioport

Even if the debug options are kept they should be streamlined along
the same
pattern:

>> --debug-single-step Enable single stepping
>> --debug-ioport Enable ioport debugging

But having a --debug option that recognizes all the debug flags would
be nicer.

It would also allow future enhancements to group debug features, like:

--debug all # turn on everything and the kitchen sink
for early hangs
--debug all,-single-step # turn on everything except single-step
debugging
--debug nonverbose # turn on all non-noisy debug options we
have

Maybe even:

--debug memcheck

... could run kvm under valgrind automatically - that way we can hide
any secondary tool complexities from the user and turn those tools into
simple debug options :-)
'''

Let's do this --debug option consolidation later.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Lookup symbol based on RIP for 'kill -3'

To make debugging easier, look up symbol from guest kernel image based on RIP
when user does 'kill -3' to the hypervisor.

Example output looks as

kvm tools: Lookup symbol based on RIP for 'kill -3'

To make debugging easier, look up symbol from guest kernel image based on RIP
when user does 'kill -3' to the hypervisor.

Example output looks as follows:

Code:
-----
rip: [<ffffffff812cb3a0>] delay_loop+30 (/home/penberg/linux/arch/x86/lib/delay.c:32)

Cc: Asias He <asias.hejun@gmail.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix typo in converting bytes to MBs

Signed-off-by: Pekka Enberg <penberg@kernel.org>

kvm tools: Print out important command line options at startup

It's important to know what the guest configuration looks like when debugging
issues so print out important command line options at sta

kvm tools: Print out important command line options at startup

It's important to know what the guest configuration looks like when debugging
issues so print out important command line options at startup:

$ ./kvm run -k ../../arch/x86/boot/bzImage -m 512
# kvm run -k ../../arch/x86/boot/bzImage -m 512 -c 1

Suggested-by: Ingo Molnar <mingo@elte.hu>
Cc: Asias He <asias.hejun@gmail.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Use '-c' for '--cpus', not '--console'

This patch changes the '-c' command line option to specify the number of CPUs
because it's used more often than console switching.

Cc: Asias He <as

kvm tools: Use '-c' for '--cpus', not '--console'

This patch changes the '-c' command line option to specify the number of CPUs
because it's used more often than console switching.

Cc: Asias He <asias.hejun@gmail.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Rename 'self' variables

Give proper names to vars named 'self'.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

kvm tools: Add debug() helper

Useful for debugging. It adds "--debug" option as well so
debug prints are seen only if user asked for them.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed

kvm tools: Add debug() helper

Useful for debugging. It adds "--debug" option as well so
debug prints are seen only if user asked for them.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Dump vCPUs in order

* Ingo Molnar <mingo@elte.hu> wrote:

> The patch below addresses these concerns, serializes the output, tidies up the
> printout, resulting in this new output:

There

kvm tools: Dump vCPUs in order

* Ingo Molnar <mingo@elte.hu> wrote:

> The patch below addresses these concerns, serializes the output, tidies up the
> printout, resulting in this new output:

There's one bug remaining that my patch does not address: the vCPUs are not
printed in order:

# vCPU #0's dump:
# vCPU #2's dump:
# vCPU #24's dump:
# vCPU #5's dump:
# vCPU #39's dump:
# vCPU #38's dump:
# vCPU #51's dump:
# vCPU #11's dump:
# vCPU #10's dump:
# vCPU #12's dump:

This is undesirable as the order of printout is highly random, so successive
dumps are difficult to compare.

The patch below serializes the signalling itself. (this is on top of the
previous patch)

The patch also tweaks the vCPU printout line a bit so that it does not start
with '#', which is discarded if such messages are pasted into Git commit
messages.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix and improve the CPU register dump debug output code

* Pekka Enberg <penberg@kernel.org> wrote:

> Ingo Molnar reported that 'kill -3' didn't work on his machine:
>
> * Ingo Molnar <

kvm tools: Fix and improve the CPU register dump debug output code

* Pekka Enberg <penberg@kernel.org> wrote:

> Ingo Molnar reported that 'kill -3' didn't work on his machine:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > This is really cumbersome to debug - is there some good way to get to the RIP
> > that the guest is hanging in? If kvm would print that out to the host console
> > (even if it's just the raw RIP initially) on a kill -3 that would help
> > enormously.
>
> Looks like the code should be doing that already - but the ioctl(KVM_GET_SREGS)
> hangs:
>
> [pid 748] ioctl(6, KVM_GET_SREGS
>
> Avi Kivity pointed out that it's not safe to call KVM_GET_SREGS (or other vcpu
> related ioctls) from other threads:
>
> > is it not OK to call KVM_GET_SREGS from other threads than the one
> > that's doing KVM_RUN?
>
> From Documentation/kvm/api.txt:
>
> - vcpu ioctls: These query and set attributes that control the operation
> of a single virtual cpu.
>
> Only run vcpu ioctls from the same thread that was used to create the
> vcpu.
>
> Fix that up by using pthread_kill() to force the threads that are doing KVM_RUN
> to do the register dumps.
>
> Reported: Ingo Molnar <mingo@elte.hu>
> Cc: Asias He <asias.hejun@gmail.com>
> Cc: Avi Kivity <avi@redhat.com>
> Cc: Cyrill Gorcunov <gorcunov@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Prasad Joshi <prasadjoshi124@gmail.com>
> Cc: Sasha Levin <levinsasha928@gmail.com>
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
> ---
> tools/kvm/kvm-run.c | 20 +++++++++++++++++---
> 1 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
> index eb50b6a..58e2977 100644
> --- a/tools/kvm/kvm-run.c
> +++ b/tools/kvm/kvm-run.c
> @@ -127,6 +127,18 @@ static const struct option options[] = {
> OPT_END()
> };
>
> +static void handle_sigusr1(int sig)
> +{
> + struct kvm_cpu *cpu = current_kvm_cpu;
> +
> + if (!cpu)
> + return;
> +
> + kvm_cpu__show_registers(cpu);
> + kvm_cpu__show_code(cpu);
> + kvm_cpu__show_page_tables(cpu);
> +}
> +
> static void handle_sigquit(int sig)
> {
> int i;
> @@ -134,9 +146,10 @@ static void handle_sigquit(int sig)
> for (i = 0; i < nrcpus; i++) {
> struct kvm_cpu *cpu = kvm_cpus[i];
>
> - kvm_cpu__show_registers(cpu);
> - kvm_cpu__show_code(cpu);
> - kvm_cpu__show_page_tables(cpu);
> + if (!cpu)
> + continue;
> +
> + pthread_kill(cpu->thread, SIGUSR1);
> }
>
> serial8250__inject_sysrq(kvm);

i can see a couple of problems with the debug printout code, which currently
produces a stream of such dumps for each vcpu:

Registers:
rip: 0000000000000000 rsp: 00000000000016ca flags: 0000000000010002
rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000
rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000
rbp: 0000000000008000 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cr0: 0000000060000010 cr2: 0000000000000070 cr3: 0000000000000000
cr4: 0000000000000000 cr8: 0000000000000000
Segment registers:
register selector base limit type p dpl db s l g avl
cs f000 00000000000f0000 0000ffff 03 1 3 0 1 0 0 0
ss 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
ds 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
es 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
fs 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
gs 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
tr 0000 0000000000000000 0000ffff 0b 1 0 0 0 0 0 0
ldt 0000 0000000000000000 0000ffff 02 1 0 0 0 0 0 0
gdt 0000000000000000 0000ffff
idt 0000000000000000 0000ffff
[ efer: 0000000000000000 apic base: 00000000fee00900 nmi: enabled ]
Interrupt bitmap:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <cf> eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 f6 c4 0e 75 4b
Stack:
0x000016ca: 00 00 00 00 00 00 00 00
0x000016d2: 00 00 00 00 00 00 00 00
0x000016da: 00 00 00 00 00 00 00 00
0x000016e2: 00 00 00 00 00 00 00 00

The problems are:

- This does not work very well on SMP with lots of vcpus, because the printing
is unserialized, resulting in a jumbled mess of an output, all vcpus trying
to print to the console at once, often mixing lines and characters randomly.

- stdout from a signal handler must be flushed, otherwise lines can remain
buffered if someone saves the output via 'tee' for example.

- the dumps from the various CPUs are not distinguishable - they are just
dumped after each other with no identification

- the various printouts are rather hard to parse visually - it's not easy to see
various properties "at a glance" because the dump is visually confusing.

The patch below addresses these concerns, serializes the output, tidies up the
printout, resulting in this new output:

#
# vCPU #0's dump:
#

Registers:
----------
rip: 0000000000000000 rsp: 00000000000008bc flags: 0000000000010002
rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000
rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000
rbp: 0000000000008000 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cr0: 0000000060000010 cr2: 0000000000000070 cr3: 0000000000000000
cr4: 0000000000000000 cr8: 0000000000000000

Segment registers:
------------------
register selector base limit type p dpl db s l g avl
cs f000 00000000000f0000 0000ffff 03 1 3 0 1 0 0 0
ss 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
ds 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
es 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
fs 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
gs 1000 0000000000010000 0000ffff 03 1 3 0 1 0 0 0
tr 0000 0000000000000000 0000ffff 0b 1 0 0 0 0 0 0
ldt 0000 0000000000000000 0000ffff 02 1 0 0 0 0 0 0
gdt 0000000000000000 0000ffff
idt 0000000000000000 0000ffff

APIC:
-----
efer: 0000000000000000 apic base: 00000000fee00900 nmi: enabled

Interrupt bitmap:
-----------------
0000000000000000 0000000000000000 0000000000000000 0000000000000000

Code:
-----
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <cf> eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 f6 c4 0e 75 4b

Stack:
------
0x000008bc: 00 00 00 00 00 00 00 00
0x000008c4: 00 00 00 00 00 00 00 00
0x000008cc: 00 00 00 00 00 00 00 00
0x000008d4: 00 00 00 00 00 00 00 00

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Add missing space after kernel params

Add missing space so that user-provided kernel params
will be properly concatenated to default params.

Instead of just adding a space at the end, ad

kvm tools: Add missing space after kernel params

Add missing space so that user-provided kernel params
will be properly concatenated to default params.

Instead of just adding a space at the end, add it with
a separate strcat(), since it's not the first (and wouldn't
have been the last) time a space wasn't added.

Reported-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix 'kill -3' hangs

Ingo Molnar reported that 'kill -3' didn't work on his machine:

* Ingo Molnar <mingo@elte.hu> wrote:

> This is really cumbersome to debug - is there some good wa

kvm tools: Fix 'kill -3' hangs

Ingo Molnar reported that 'kill -3' didn't work on his machine:

* Ingo Molnar <mingo@elte.hu> wrote:

> This is really cumbersome to debug - is there some good way to get to the RIP
> that the guest is hanging in? If kvm would print that out to the host console
> (even if it's just the raw RIP initially) on a kill -3 that would help
> enormously.

Looks like the code should be doing that already - but the ioctl(KVM_GET_SREGS)
hangs:

[pid 748] ioctl(6, KVM_GET_SREGS

Avi Kivity pointed out that it's not safe to call KVM_GET_SREGS (or other vcpu
related ioctls) from other threads:

> is it not OK to call KVM_GET_SREGS from other threads than the one
> that's doing KVM_RUN?

From Documentation/kvm/api.txt:

- vcpu ioctls: These query and set attributes that control the operation
of a single virtual cpu.

Only run vcpu ioctls from the same thread that was used to create the
vcpu.

Fix that up by using pthread_kill() to force the threads that are doing KVM_RUN
to do the register dumps.

Reported: Ingo Molnar <mingo@elte.hu>
Cc: Asias He <asias.hejun@gmail.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Enable earlyprintk=serial by default

Enable the earlyprintk console to the serial port, to allow the debugging of
very early hangs/crashes.

Since we already enable the serial console by

kvm tools: Enable earlyprintk=serial by default

Enable the earlyprintk console to the serial port, to allow the debugging of
very early hangs/crashes.

Since we already enable the serial console by default, this is a natural
extension of it.

I have tested that it indeed works, by provoking an early hang that triggers
after the early console is enabled by before the real console is registered. In
that case before the patch we get:

$ ./kvm run --cpus 2
[ silent hang ]

With this patch applied i got the early output:

$ ./kvm run --cpus 60
[ 0.000000] console [earlyser0] enabled
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.39-rc6-tip-02944-g87b0bcf-dirty (mingo@aldebaran) (gcc version 4.6.0 20110419 (Red Hat 4.6.0-5) (GCC) ) #84 SMP Mon May 9 02:34:26 CEST 2011
[ 0.000000] Command line: notsc noapic noacpi pci=conf1 console=ttyS0 earlyprintk=serialroot=/dev/vda1 rw
[ 0.000000] locking up the box!

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Warn if guest RAM size exceeds host RAM size

Guest memory size that's larger than host physical RAM can cause swap deaths on
the host so warn the user about it.

Cc: Asias He <asias.hejun

kvm tools: Warn if guest RAM size exceeds host RAM size

Guest memory size that's larger than host physical RAM can cause swap deaths on
the host so warn the user about it.

Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Suggested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Don't use all of host RAM for guests by default

This patch fixes the default guest RAM size maximum to 80% of the host RAM to
avoid swapping the host to death.

Cc: Asias He <asias.hejun@

kvm tools: Don't use all of host RAM for guests by default

This patch fixes the default guest RAM size maximum to 80% of the host RAM to
avoid swapping the host to death.

Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Suggested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Limit CPU count by KVM_CAP_NR_VCPUS

This patch limits the number of CPUs to KVM_CAP_NR_VCPUS when user specifies
more CPUs with the "--cpus=N" command line option than what the in-kernel

kvm tools: Limit CPU count by KVM_CAP_NR_VCPUS

This patch limits the number of CPUs to KVM_CAP_NR_VCPUS when user specifies
more CPUs with the "--cpus=N" command line option than what the in-kernel KVM
is able to handle.

Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Scale guest RAM size by CPU count

This patch increases default RAM size to 256 for one CPU and introduces RAM
size linear scaling based on CPUs as suggested by Ingo Molnar:

64MB*(nr

kvm tools: Scale guest RAM size by CPU count

This patch increases default RAM size to 256 for one CPU and introduces RAM
size linear scaling based on CPUs as suggested by Ingo Molnar:

64MB*(nr_cpus + 3)

------------------
1 CPUs: 256 MB
2 CPUs: 320 MB
3 CPUs: 384 MB
4 CPUs: 448 MB
5 CPUs: 512 MB
6 CPUs: 576 MB
7 CPUs: 640 MB
8 CPUs: 704 MB
9 CPUs: 768 MB
10 CPUs: 832 MB
11 CPUs: 896 MB
12 CPUs: 960 MB
13 CPUs: 1024 MB
14 CPUs: 1088 MB
15 CPUs: 1152 MB
16 CPUs: 1216 MB

Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Prasad Joshi <prasadjoshi124@gmail.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Suggested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Dynamically add devices when creating mptable

Enumerate registered devices to build a complete
and updated mptable containing all registered pci
devices.

Signed-off-by: Sasha Levin <levi

kvm tools: Dynamically add devices when creating mptable

Enumerate registered devices to build a complete
and updated mptable containing all registered pci
devices.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Simplify search for root device

Use /dev/block to find the block device used for root
instead of searching through mounts.

Tested-by: Prasad Joshi <prasadjoshi124@gmail.com>
Signed-off-b

kvm tools: Simplify search for root device

Use /dev/block to find the block device used for root
instead of searching through mounts.

Tested-by: Prasad Joshi <prasadjoshi124@gmail.com>
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Enable SMP support

This patch enables SMP support:

[ 0.155072] Brought up 3 CPUs
[ 0.155074] Total of 3 processors activated (15158.58 BogoMIPS).

virtio-console was being loaded n

kvm tools: Enable SMP support

This patch enables SMP support:

[ 0.155072] Brought up 3 CPUs
[ 0.155074] Total of 3 processors activated (15158.58 BogoMIPS).

virtio-console was being loaded no matter the cmdline options
and it was causing some hangs (have to look into that).

I'll send this patch to a larger audience once someone
else can confirm it actually works/doesn't work.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix loading root device as image

Fix the loading of root device when no image name was
specified.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penber

kvm tools: Fix loading root device as image

Fix the loading of root device when no image name was
specified.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...