- 01 Jun, 2015 40 commits
-
-
Andre Przywara authored
lkvm -i is currently broken on ARM/ARM64. We should not try to convert smaller-than-4GB addresses into 64-bit big endian and then stuff them into u32 variables if we expect to read anything other than 0 out of it. Adjust the type to u64 to write the proper address in BE format into the /chosen node (and also match the address size we formely posted) and let Linux thus read the right values. This fixes initrd functionality for ARM and ARM64 guests. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Suzuki Poulose authored
lkvm by default sets up a virtio-pci transport for network, if none is specified. This can be a problem on archs (e.g ARM64), where virtio-pci is not supported yet and cause the following warning at exit. # KVM compatibility warning. virtio-net device was not detected. This patch changes it to make use of the default transport method for the architecture when none is specified. This will ensure that on every arch we get the network up by default in the VM. Signed-off-by:
Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by:
-
Anup Patel authored
If in-kernel KVM support PSCI-0.2 emulation then we should set KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also provide "arm,psci-0.2","arm,psci" as PSCI compatible string. This patch updates kvm_cpu__arch_init() and setup_fdt() as per above. Signed-off-by:
Pranavkumar Sawargaonkar <pranavkumar@linaro.org> Signed-off-by:
Anup Patel <anup.patel@linaro.org> Reviewed-by:
-
Anup Patel authored
The KVM_EXIT_SYSTEM_EVENT exit reason was added to define architecture independent system-wide events for a Guest. Currently, it is used by in-kernel PSCI-0.2 emulation of KVM ARM/ARM64 to inform user space about PSCI SYSTEM_OFF or PSCI SYSTEM_RESET request. For now, we simply treat all system-wide guest events as shutdown request in KVMTOOL. Signed-off-by:
-
Anup Patel authored
The VCPU target type KVM_ARM_TARGET_XGENE_POTENZA is available in latest Linux-3.16-rcX or higher hence register aarch64 target type for it. This patch enables us to run KVMTOOL on X-Gene Potenza host. Signed-off-by:
-
Anup Patel authored
Instead, of trying out each and every target type we should use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type for KVM ARM/ARM64. If KVM_ARM_PREFERRED_TARGET vm ioctl fails then we fallback to old method of trying all known target types. If KVM_ARM_PREFERRED_TARGET vm ioctl succeeds but the returned target type is not known to KVMTOOL then we forcefully init VCPU with target type returned by KVM_ARM_PREFERRED_TARGET vm ioctl. Signed-off-by:
-
Will Deacon authored
The kernel now exposes register accessor macros in the uapi/ headers for arm and arm64, so use those instead (and avoid the compile failure from the duplicate definitions). Signed-off-by: -
Konstantin Khlebnikov authored
Fix trivial overflow of u32 value Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
Pekka Enberg <penberg@kernel.org>
-
Andreas Herrmann authored
Use struct kvm_cpu instead of struct kvm. This change is req'd due to commit 8d770c4096cdf73e1b79e7395ef3a86aa2887077 (kvmtool: virtio: pass trapped vcpu to IO accessors). Signed-off-by:
Andreas Herrmann <andreas.herrmann@caviumnetworks.com> Signed-off-by:
-
Joel Schopp authored
Currently tools/kvm doesn't build on arm64 when gtk3 is present. The error looks like this: LINK lkvm ui/gtk3.o: In function `kvm_gtk_key_press': /extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:201: undefined reference to `kbd_queue' /extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:204: undefined reference to `kbd_queue' /extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:216: undefined reference to `kbd_queue' /extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:217: undefined reference to `kbd_queue' /extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:218: undefined reference to `kbd_queue' ui/gtk3.o:/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:219: more undefined references to `kbd_queue' follow collect2: error: ld returned 1 exit status make: *** [lkvm] Error 1 The patch below makes the error go away and the resulting lkvm runs on arm64. Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by:
Joel Schopp <joel.schopp@amd.com> Signed-off-by:
-
Marc Zyngier authored
The new optional property "always-on" indicates that the timers are, well, always on when used with KVM. This allows for substantial performance improvement in the guest (it switches to NOHZ instead of using a periodic tick per vcpu) and removes a lot of burden from the host (no need to inject tons of interrupts with the associated rescheduling overhead). Old kernels that don't understand this property will simply ignore it. Acked-by:
-
Andreas Herrmann authored
No caller is currently using the return value but better return number of bytes written instead of 0 in case of an error. Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
David Daney authored
It is a performance enhancement. When running in a simulator, each system call to write a character takes a lot of time. Batching them up decreases the overhead (in the root kernel) of each virtio console write. Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
David Daney authored
Signed-off-by:
-
David Daney authored
It doesn't work on big endian hosts as is. Signed-off-by:
-
David Daney authored
Signed-off-by:
-
Andreas Herrmann authored
This is is usually 0 for most archs. On mips we have two types. TE (type 0) and MIPS-VZ (type 1). Default to 1 on mips. Signed-off-by:
-
David Daney authored
So far this was tested with host running KVM using MIPS-VZ (on Cavium Octeon3). A paravirtualized mips kernel was used for the guest. Signed-off-by:
-
Andreas Herrmann authored
... to get rid of its function definition from archs that don't support it. Signed-off-by:
-
Andreas Herrmann authored
Signed-off-by:
-
Andreas Herrmann authored
In order to use it in other C files (in addition to term.c). Signed-off-by:
-
Andreas Herrmann authored
This should fix following warnings builtin-stat.c:93:3: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 2 has type '__u64' [-Wformat] builtin-run.c:188:4: warning: format '%Lu' expects argument of type 'long long unsigned int', but argument 3 has type '__u64' [-Wformat] builtin-run.c:554:3: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 2 has type 'u64' [-Wformat] builtin-run.c:554:3: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'u64' [-Wformat] builtin-run.c:645:3: warning: format '%Lu' expects argument of type 'long long unsigned int', but argument 4 has type 'u64' [-Wformat] disk/core.c:330:4: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type '__dev_t' [-Wformat] disk/core.c:330:4: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__dev_t' [-Wformat] disk/core.c:330:4: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__ino64_t' [-Wformat] mmio.c:134:5: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'u64' [-Wformat] util/util.c:101:7: warning: format '%lld' expects argument of type 'long long int', but argument 3 has type 'u64' [-Wformat] util/util.c:113:7: warning: format '%lld' expects argument of type 'long long int', but argument 2 has type 'u64' [-Wformat] hw/pci-shmem.c:339:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 'u64' [-Wformat] hw/pci-shmem.c:340:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 'u64' [-Wformat] as observed when compiling on mips64. Signed-off-by:
-
David Daney authored
Signed-off-by:
-
Marc Zyngier authored
The recent introduction of bi-endianness on arm/arm64 had the odd effect of breaking virtio-pci support on these platforms, as the device endian field defaults to being VIRTIO_ENDIAN_HOST, which is the wrong thing to have on a bi-endian capable architecture. The fix is to check for the endianness on the ioport path the same way we do it for mmio, which implies passing the vcpu all the way down. Patch is a bit ugly, but aligns MMIO and ioport nicely. Tested on arm64 and x86. Acked-by:
-
Marc Zyngier authored
Implement the kvm_cpu__get_endianness call for both AArch32 and AArch64, and advertise the bi-endianness support. Signed-off-by:
-
Marc Zyngier authored
Configure the queues to follow the guest endianness, and make sure the configuration space is doing the same. Extra care is taken for the handling of the virtio_net_hdr structures on both the TX and RX ends. Signed-off-by:
-
Marc Zyngier authored
Configure the queues to follow the guest endianness, and make sure the configuration space is doing the same. Signed-off-by:
-
Marc Zyngier authored
Configure the queues to follow the guest endianness, and make sure the configuration space is doing the same. Signed-off-by:
-
Marc Zyngier authored
Configure the queues to follow the guest endianness, and make sure the configuration space is doing the same. Signed-off-by:
-
Marc Zyngier authored
Add a utility function that transfers the endianness sampled at device reset time to a queue being set up. Signed-off-by:
-
Marc Zyngier authored
Save the CPU endianness when the device is reset. It is widely assumed that the guest won't change its endianness after, or at least not without reseting the device first. A default implementation of the endianness sampling just returns the default "host endianness" value so that unsuspecting architectures are not affected. Signed-off-by:
-
Marc Zyngier authored
Define a simple infrastructure to configure a virt_queue depending on the guest endianness, as reported by the feature flags. At this stage, the endianness is always the host's. Wrap all accesses to virt_queue data structures shared between host and guest with byte swapping helpers. Should the architecture only support one endianness, these helpers are reduced to the identity function. Signed-off-by:
-
Marc Zyngier authored
In order to be able to find out about the endianness of a virtual CPU, it is necessary to pass a pointer to the kvm_cpu structure down to the MMIO accessors. This patch just pushes such pointer as far as required for the MMIO accessors to have a play with the vcpu. Signed-off-by:
-
Marc Zyngier authored
In order to overcome the fact that a TAP interface can only be created by root, allow the use of an interface that has already been created, configured, made persistent and owned by a specific user/group (such as done with tunctl). In this case, any kind of configuration can be skipped (IP, up and running mode), and the TAP is assumed to be ready for use. This is done by introducing the "tapif" option, as used here: --network trans=mmio,mode=tap,tapif=blah where "blah" is a TAP interface. This allow the creation/configuration of the interface to be controlled by root, and lkvm to be run as a normal user. Signed-off-by:
-
Marc Zyngier authored
The --tty option allows the redirection of a console (serial or virtio) to a pseudo-terminal. As long as the slave port of this pseudo-terminal is not opened by another process, a poll() call on the master port will return POLLHUP in the .event field. This confuses the virtio console code, as term_readable() returns a positive value, indicating that something is available, while the call to term_getc_iov will fail. The fix is to check for the presence of the POLLIN flag in the .event field. Note that this is only a partial fix, as kvmtool will still consume vast amounts of CPU resource by spinning like crazy until the slave port is actually opened. Signed-off-by:
-
Marc Zyngier authored
If the host kernel is configured with CONFIG_TRANSPARENT_HUGEPAGE_MADVISE, it is important to madvise(MADV_HUGEPAGE) the memory region. Otherwise, the guest won't benefit from using THP. Acked-by:
-
Marc Zyngier authored
Use of THP requires that the VMA containing the guest memory is 2MB aligned. Unfortunately, nothing in kvmtool ensures that the memory is actually aligned, making the use of THP very unlikely. Just follow what we're already doing for virtio, and expand our forced alignment to 2M. * without this patch: root@muffin-man:~# for i in $(seq 1 5); do ./hackbench 50 process 1000; done Running with 50*40 (== 2000) tasks. Time: 113.600 Running with 50*40 (== 2000) tasks. Time: 108.650 Running with 50*40 (== 2000) tasks. Time: 110.753 Running with 50*40 (== 2000) tasks. Time: 116.992 Running with 50*40 (== 2000) tasks. Time: 117.317 * with this patch: root@muffin-man:~# for i in $(seq 1 5); do ./hackbench 50 process 1000; done Running with 50*40 (== 2000) tasks. Time: 97.613 Running with 50*40 (== 2000) tasks. Time: 96.111 Running with 50*40 (== 2000) tasks. Time: 97.090 Running with 50*40 (== 2000) tasks. Time: 100.820 Running with 50*40 (== 2000) tasks. Time: 100.298 Acked-by:
-
Will Deacon authored
Whilst our IO port is fixed at CPU physical address 0x0, changing ARM_IOPORT_AREA should be all that's necessary to move it around in CPU physical space (it will still be at 0x0 in the bus address space). This patch ensures we subtract KVM_IOPORT_AREA from the faulting CPU physical address when calculating the port for kvm__emulate_io. Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Will Deacon authored
Now that the dust has settled on the devicetree bindings for the generic PCI host controller in the Linux kernel, update the node generated by kvmtool to match what mainline kernels will expect. Signed-off-by:
-
Sasha Levin authored
Upstream commit "9p: Modify the stat structures to use kuid_t and kgid_t" has modified the type of uid and gid in the stat structure, which breaks build for us. This is a rather trivial conversion from u32 to kuid_t and kgid_t. Reported-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
