kvmtools uses the virtual CPU number to emit the DT CPU nodes.
While this is correct for a flat topology, it fails on anything
else, as the guest expects to find the MPIDR there.
The fix is to ask the kernel for each vcpu MPIDR, and emit this
instead.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The Cortex-A7 is very similar to the Cortex-A15 and as such there is very
little extra infrastructure required for KVM tool to be able to create
A7-guests.
This patch adds the basic support and allows booting of A7 guests on A7
hosts. It depends on Cortex-A7 support patches posted recently to the kvmarm
list.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The ARM V7 and V8 CPUs use the nearly identical support code for generating
timer DT nodes as they both use ARM's architected timers. This code is currently
duplicated for AArch32 and AArch64.
This cleanup patch generalises timer DT node generation to follow the same
pattern as for the GIC. The ability of a DT node to contain multiple compatible
strings is exploited to allow an identical DT node to be used on V7 and V8
platforms.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Milan Kocian writes:
I found the crash in virtio-net-rx thread (I can reproduce it every
time by 'aptitude update' in VM):
traps: virtio-net-rx[28933] general protection ip:7f00dda3d107 sp:7f00c58f4de8 error:0 in libc-2.17.so[7f00dd90f000+1a2000]
gdb backtrace:
(gdb) bt
#0 0x00007fb6a548e107 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x000000000041259c in memcpy_toiovecend (iov=0x7fb68d346ea0, iov@entry=0x7fb68d345e90,
kdata=<optimized out>, kdata@entry=0x7fb68d346e90 "", offset=<optimized out>, len=<optimized out>)
at util/iovec.c:70
#2 0x000000000040c66d in virtio_net_rx_thread (p=0x23688a0) at virtio/net.c:117
#3 0x00007fb6a5b2ee0e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007fb6a54489ed in clone () from /lib/x86_64-linux-gnu/libc.so.6
I tried to add some printf to diagnose it but it isn't clear to me:
virtio_net_rx_thread: before memcpy_toiovecend; copied: 0, len: 18890, iovsize: 4096, realiovsize: 4096
memcpy_toiovecend: offset: 0, len: 4096
memcpy_toiovecend: iov_len: 4096, len: 4096
virtio_net_rx_thread: before memcpy_toiovecend; copied: 4096, len: 18890, iovsize: 4096, realiovsize: 4096
memcpy_toiovecend: offset: 4096, len: 4096
memcpy_toiovecend: iov_len: 4096, len: 4096
memcpy_toiovecend: iov_len: 0, len: 4096
memcpy_toiovecend: iov_len: 0, len: 4096
.
N x memcpy_toiovecend: iov_len: 0, len: 4096
.
memcpy_toiovecend: iov_len: 0, len: 4096
memcpy_toiovecend: iov_len: 0, len: 4096
memcpy_toiovecend: iov_len: 1519143547641528320, len: 4096
memcpy_toiovecend: iov_len: 193827583623176, len: 4096
./runlkvm.sh: line 2: 16090 Segmentation fault
IMHO problem come when received len size is bigger than maximum of the
dst iovec (realiovsize). Only iovec size is copied and in the next run
isn't place to copy the rest of len size.
Asias He writes:
We should skip copied bytes from the buffer not from the iov itself
which memcpy_toiovecend does.
Reported-and-tested-by: Milan Kocian <milon@wq.cz>
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@iki.fi>
The asynchronous nature of the virtio input handling (using a job queue)
can result in unnecessary jobs being created if there is some delay in
handing input (the original function to handle the input returns immediately
without the file having been read, and hence poll returns immediately
informing us of data to read).
This patch adds synchronisation to the threads so that we don't start
polling input files again until we've read from the console.
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Currently the only use of the periodic timer tick in kvmtool is to
handle reading from stdin. Though functional, this periodic tick can be
problematic on slow (eg FPGA) platforms and can cause low interactivity or
even stop the execution from progressing at all.
This patch removes the periodic tick in favour of a dedicated thread blocked
waiting for input from the console. In order to reflect the new behaviour,
the old 'kvm__arch_periodic_tick' function is renamed to 'kvm__arch_read_term'.
In making this change it is necessary to actively flush the emulated serial
console's output buffer after the guest writes to it, as otherwise flushing
only happens with terminal input. Similarly, it is no longer necessary to
flush the buffer when we process input.
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Though there may be no near-term plans to change the number of terminal
devices in the future, using TERM_MAX_DEVS instead of '4' makes reading
some of the loops over terminal devices clearer.
This patch makes the this substitution where required.
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
A recent fix to virtio MMIO (72a7541ce305 ["kvm tools: virtio-mmio:
init_ioeventfd should use MMIO for ioeventfd__add_event()"]) highlighted
the confusing parameters expected by ioeventfd__add_event.
As per Pekka's suggestion, replace the bool parameters to this function
with a single `flags' argument instead.
Cc: Ying-Shiuan Pan <yingshiuan.pan@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch fixes a bug that vtirtio_mmio_init_ioeventfd() passed a wrong
value when it invoked ioeventfd__add_event(). True value of 2nd parameter
indicates the eventfd uses PIO bus which is used by virito-pci, however,
for virtio-mmio, the value should be false.
Signed-off-by: Ying-Shiuan Pan <yspan@itri.org.tw>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
xics_init() assumes kvm->nrcpus is already setup. kvm->nrcpus is setup
in kvm_cpu_init()
Unfortunately xics_init() and kvm_cpu_init() both use base_init(). So
depending on the order randomly determined by the compiler, xics_init()
may initialised see kvm->nrcpus as 0 and not setup any of the icp VCPU
pointers. This manifests itself later in boot when trying to raise an
IRQ resulting in a null pointer deference/segv.
This moves xics_init() to use dev_base_init() to ensure it happens after
kvm_cpu_init().
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
On some powerpc systems, reboot is implemented by an RTAS call by the
name of "system-reboot". Currently we don't implement it in kvmtool,
which means instead the guest prints an error and spins.
This is particularly annoying because when the guest kernel panics it
will try to reboot, and end up spinning in the guest.
We can't implement reboot properly, ie. causing a reboot, but it's still
preferable to implement it as halt rather than not implementing it at
all.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
On powerpc we build kvmtool as a 64bit binary. We do that by setting
-m64 in our CFLAGS. For most things we just call $(CC) and it passes
that info onto the linker.
However there is one place where we explicitly call the linker, in the
build of guest/init - and in that case we need to tell the linker to
build 64bit.
We have gotten away with this so far because we have been building with
a 64bit only toolchain. However if you build with a biarch toolchain,
which generally defaults to 32bit, we fail to link.
The fix is to defined LDFLAGS appropriately and pass it to LD.
Tested on powerpc and x86-64.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
When fa7226f (kvm tools: init network devices only when the virtio
driver is ready to go) was introduced, a tiny detail was overlooked:
- Initialization of the uip layer is now coming in very late (only
when the guest driver says it is ready).
- In parallel, the rx thread is created quite early (as soon as the
queues are allocated).
This cause the rx thread to call uip_rx, which calls uip_buf_get_used,
which starts to use buf_lock mutex/the buf_used_cond, which haven't
been initialized yet. Tears and devastation follow, not to mention a
certain lack of network connectivity for the unsuspecting guest.
The (not so pretty) fix is to split uip_init:
- uip_static_init: initialize the lists, mutexes and conditions,
called from virtio_net__init_one.
- uip_init: perform the dynamic memory allocations, called from
notify_status.
This allows the network to be safely initialized.
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Asias writes:
In include/kvm/virtio-scsi.h, we have
/* TODO: Remove this when tcm_vhost goes upstream */
We are redefining VHOST_SCSI_GET_ABI_VERSION and friends because
tcm_vhost was not upstream at that time. Pekka, I guess we need to
upgrade kernel version in lkvm repo and drop our own tcm_vhost
defines.
Ingo writes:
I can confirm that the patch below fixes the build problem.
Analyzed-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This makes SeaBIOS limp along all the way to boot menu:
[penberg@tux kvm]$ ./vm run --firmware /usr/share/seabios/bios.bin
# lkvm run -k ../../arch/x86/boot/bzImage -m 448 -c 4 --name guest-11658
Start bios (version 0.6.0)
Unable to unlock ram - bridge not found
Ram Size=0x00100000 (0x0000000000000000 high)
CPU Mhz=13
Found 1 cpu(s) max supported 1 cpu(s)
PCI: bus=0 devfn=0x08: vendor_id=0x1af4 device_id=0x1009
PCI: bus=0 devfn=0x10: vendor_id=0x1af4 device_id=0x1009
PCI: bus=0 devfn=0x18: vendor_id=0x1af4 device_id=0x1000
region 0: 0x00000000
region 1: 0x00000000
WARNING - Unable to allocate resource at mptable_init:26!
WARNING - Unable to allocate resource at smbios_init:381!
Scan for VGA option rom
WARNING - Timeout at i8042_wait_read:35!
Found 2 lpt ports
Found 4 serial ports
Scan for option roms
Press F12 for boot menu.
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Commit "kvm tools: virtio: remove hardcoded assumptions
about guest page size" has introduced a bug that prevented
guests with more than 4gb of ram from booting.
The issue is that 'pfn' is a 32bit integer, so when multiplying
it by page size to get the actual page will cause an overflow if
the pfn referred to a memory area above 4gb.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Patch e03b449cbddf (kvm tools: add status notification hook for
virtio) converted virtio-net to use a new notification mechanism,
but unfortunately left virtio-mmio behind.
The direct consequence is that both arm and arm64 guests are left
without any form of networking. Not good.
Bring virtio-mmio into this brave new notified world, and feel the
power of being able to ping again.
Acked-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: Asias He <asias.hejun@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Some filesystems don't return valid d_type field in dirent
structure (e.g XFS). So we must handle this case properly.
Signed-off-by: Milan Kocian <milon@wq.cz>
Cc: Sasha Levin <levinsasha928@gmail.com>
[ penberg@kernel.org: cleanups ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Support mergable rx buffers for virtio-net. This helps reduce the amount
of memory the guest kernel has to allocate per rx vq.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
They're hidden inside net/core/iovec.c. It'd be nice to just link to that
but they're not too generic and come with tons of net/ specific code we
don't want. So we just copy over the relevant parts.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
vnet header size depends on whether we use mergable rx buffers.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We may need to know what features are supported before we can init the
network on the host side.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Some devices want to know their status, use this hook to allow them to
get that notification.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We broke networking using vhost with the introduction of a ctrl vq,
make sure that that queue get treated like a special case.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We want to make the size of the virtio net header opaque to
uip.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If we're using the 8250 as a fully-fledged console (i.e. not early
console), then we need to allow input as well as output.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Now that ioport devices can generate fdt nodes, iterate over the ioport
bus when generating our fdt.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Having several uarts with the same name makes the kernel (and dtc)
choke. Add the base address as a qualifier so we get unique names.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds fdt node generation to the 8250 emulation. The
serial8250_device is now stashed inside the ioport priv field, so that
it can be retrieved from the ioport passed back to the generation code.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Devices in the ioport space may have fdt bindings (e.g. 8250, rtc) and
on architectures where a fixed ioport is not defined, it is necessary
to generate fdt nodes for them.
This patch creates a new virtual bus (tree of device_headers) for ioport
devices, allowing architecture code to callback to the emulation code
when generating fdt nodes, as we do for virtio-mmio devices.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If an architecture other than x86 wants to make use of ioport devices, the
interrupt lines will likely need remapping from their fixed values.
This patch allows an architecture callback, ioport__map_irq, to map
interrupts as appropriate.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.
This patch introduces KVM_IOPORT_AREA, which each architecture defines
to be the start of the ioport region (i.e. where port addresses are
offset from).
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Kvmtool suppresses any output to a console that has not been elected
as *the* console.
While this makes sense on the input side (we want the input to be sent
to one console driver only), it seems to be the wrong thing to do on
the output side, as it effectively prevents the guest from switching
from one console to another (think earlyprintk using 8250 to virtio
console).
After all, the guest *does* poke this device and outputs something
there.
Just remove the kvm->cfg.active_console test from the output paths.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Whilst ARM neither needs or wants a complete x86 legacy ioport emulation,
the 8250 is a useful alternative to virtio-console, so carve out 64k at the
bottom of our virtual memory map where we can add ioports if we choose.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Generating fdt nodes for virtio-mmio devices should be in the core code,
not hidden inside the architecture code for ARM.
This patch reworks the .data field of struct device_header for
virtio-mmio devices, so that it contains a function pointer which can
be called to generate the FDT node for each device.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
libfdt is used by powerpc, arm and arm64.
This patch factors out the Makefile parts including it and defines a
CONFIG_HAS_LIBFDT, so architecture-portable code can make use of fdt
if it is available.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We don't really need 64 MB of RAM to boot, it's a nice default if we
don't have anything else - but it's not actually required for anything:
sh-4.2# free -h
total used free shared buffers cached
Mem: 20M 15M 4.2M 0B 0B 4.2M
-/+ buffers/cache: 11M 8.3M
Swap: 0B 0B 0B
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch makes the maximum amount of vqs configurable. To use it pass a 'mq'
option to network device configuration. For example:
vm run -n mode=tap,mq=4
Will allow up to 4 queue pairs for that network device.
Note that not specifiying mq, or setting mq=0 will disable virtio-net
multiqueuing.
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
It's barely usable but it isn't getting any better sitting alone in a
private git branch.
You can start a new VM with the GTK UI like this:
./vm run --gtk
It's rough around the edges:
- Red and blue color channels are inverted.
- Some keys do not work.
- Mouse does not work.
- GTK assertion failure pops up on shutdown.
but I'm sure there's someone out there that's just dying to improve the
user experience.
Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Currently, SDL doesn't exit on window close because it stuck in
sdl__stop because "done" is not set to true.
Fix it by setting "done" to true on window close.
Signed-off-by: Lin Ming <minggr@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Commit 4d789d4a2050 ("kvm tools: Increase amount of possible interrupts
per PCI device") increased the maximum amount of virtio queues for the
PCI transport, but neglected to do the same for MMIO.
This patch makes the same change for virtio-mmio.
Cc: Sasha Levin <sasha.levin@oracle.com>
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The ARMv8 architecture is supported by two publicly available
software models: the Architecture Enveloppe Model, and the
Foundation model.
Both are fairly similar to the Cortex-A57 from a kvm tools point of
view, so we can hijack the A57 implementation to register these
new targets.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Now that generate_cpu_nodes uses the cpu_compatible field to
output the compatible property, we can unify the A15 and A57
implementations, as they are strictly identical.
Move the function to fdt.c, together with most of the device
tree generation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Instead of hardcoding the CPU compatible string, store it in
the target descriptor. This allows similar CPUs to be managed
by the same backend, and yet have different compatible
properties.
Also remove a check for a condition that can never occur in both
A15 and A57 backends.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If the kernel against which kvm tools was compiled supports more
CPU types than kvm tools does, then we can hit a situation where
we dereference an empty target slot.
Just stepping over empty slots fixes the issue.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds support for multiple virtio-net queues. Each queue gets
assigned to it's own corresponding rx/tx thread.
The max amount of queue pairs is 8 right now, it's up to the guest
to decide the actual amount of queues it wants using ethtool. For
example, if I want 2 queue pairs on eth0:
ethtool -L eth0 combined 2
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Marc Zyngier