- 01 Jun, 2015 40 commits
-
-
Andre Przywara authored
Similarily to the generic uapi/linux/kvm.h, each architecture carries a kvm.h header in its arch/*/include/uapi/asm directory. These contain bits for the architecture specific interface. Since we use many recent features in kvmtool, the system headers provided by the distribution are usually not up-to-date. Copy the Linux v4.1-rc6 versions of those files for all supported architectures into the kvmtool tree to get access to the full glory. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Andre Przywara authored
Some distributions with an older uapi header copy do not have all the definitions that we need (Ubuntu 12.04 comes to mind). So copy the latest versions from the Linux tree to override the system header versions. Also include virtio_mmio.h, which is technically not an uapi header, but is used in such a way. QEMU has actually a copy of these definitions in its own header file, so our approach should even be better. Those files are from a Linux v4.1-rc6 source tree, but the virtio-1.0 updates have been left out. kvmtool implements only the older version of virtio. Signed-off-by:
-
Andre Przywara authored
This file includes 9P protocol definitions which we need. Copy them from a recent Linux tree. Signed-off-by:
-
Andre Przywara authored
The uapi copy of kvm.h is usually outdated, so copy over a fresh copy from the Linux v4.1-rc6 source tree. This exercise should later be repeated when new kvmtool code requires this. It seems to be common practise in QEMU to do so. Signed-off-by:
-
Andre Przywara authored
Instead of moving the whole include file in, we just copy the needed definitions from byteorder/generic.h into the kvmtool headers. This avoids needless clutter of the include directory. Signed-off-by:
-
Andre Przywara authored
This is not really Linux specific, just a neat implementation used by kvmtool, too. Signed-off-by:
-
Andre Przywara authored
Copy some non-Linux specific header files over to the kvmtool directory. This includes generic helpers like stringify and list definitions. Signed-off-by:
-
Andre Przywara authored
The Makefile used to reference ../.. on some occasions to point to the Linux source tree. Since this is no longer there, remove those bogus paths. Since we cannot (and don't want to) determine the Linux kernel version on this way, we hardcode v3.18.0 for now, which is the version the in-kernel-tree version used at the point of forking. This should be later revisited and adjusted to whatever versioning scheme we will use. Signed-off-by:
-
Andre Przywara authored
Since kvmtool is now in a separate repository, we cannot use Linux' top-level version of the GPL license text, so copy this over. Signed-off-by:
-
Marc Zyngier authored
In order to be useable by kvmtool, a macvtap interface requires some minimal configuration (basically setting up the offload bits). This requires skipping some of the low level TUN/TAP setup. To avoid adding yet another option, we extend the 'tapif' option to detect the use of a file (such as /dev/tap23). Assuming you've run the following as root: # ip link add link eth0 name kvmtap0 type macvtap mode bridge # chgrp kvm /dev/tap$(< /sys/class/net/kvmtap0/ifindex) # chmod g+rw /dev/tap$(< /sys/class/net/kvmtap0/ifindex) it is fairly easy to have a script that does the following: #!/bin/sh addr=$(< /sys/class/net/kvmtap0/address) tap=/dev/tap$(< /sys/class/net/kvmtap0/ifindex) kvmtool/lkvm run --console virtio \ -k /boot/zImage \ -p "console=hvc0 earlyprintk" \ -n trans=mmio,mode=tap,tapif=$tap,guest_mac=$addr and you now have your VM running, directly attached to the network. This patch also removes the TUNSETNOCSUM ioctl that has declared obsolete for quite some time now... Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Suzuki Poulose authored
If an open at the 9p server(host) fails with EMFILE (Too many open files for the process), we should return ENFILE(too many open files in the system) to the guest to indicate the actual status within the guest. This was uncovered during LTP, where getdtablesize01 fails to open the maximum number-open-files. getdtablesize01 0 TINFO : Maximum number of files a process can have opened is 1024 getdtablesize01 0 TINFO : Checking with the value returned by getrlimit...RLIMIT_NOFILE getdtablesize01 1 TPASS : got correct dtablesize, value is 1024 getdtablesize01 0 TINFO : Checking Max num of files that can be opened by a process.Should be: RLIMIT_NOFILE - 1 getdtablesize01 2 TFAIL : getdtablesize01.c:102: 974 != 1023 For a more practial impact: # ./getdtablesize01 & [1] 1834 getdtablesize01 0 TINFO : Maximum number of files a process can have opened is 1024 getdtablesize01 0 TINFO : Checking with the value returned by getrlimit...RLIMIT_NOFILE getdtablesize01 1 TPASS : got correct dtablesize, value is 1024 getdtablesize01 0 TINFO : Checking Max num of files that can be opened by a process.Should be: RLIMIT_NOFILE - 1 getdtablesize01 2 TFAIL : getdtablesize01.c:102: 974 != 1023 [--- Modified to sleep indefinitely, without closing the files --- ] # ls bash: /bin/ls: Too many open files That gives a wrong error message for the bash, when getdtablesize01 has exhausted the system wide limits, giving false indicators. With the fix, we get : # ls bash: /bin/ls: Too many open files in system Acked-by:
Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Andre Przywara authored
Currently we reset the KVM interrupt line on initializing the 8250 serial device emulation. For ARM this creates a problem where we use the in-kernel IRQ chip before having fully initialized it. But with the new kernel interface we cannot finish the GIC initialization before we know the number of used IRQs, so we have to wait until all devices have been created and initialized. Since the in-kernel GIC emulation resets the IRQ line anyway and also QEMU gets away without resetting it, the easiest solution is to drop the IRQ line reset. Signed-off-by:
-
Andre Przywara authored
Among the architectures supported by kvmtool, only x86 defines a bzImage format. So we shouldn't bother users of other architectures with a message about something that cannot work. Make the bzImage check dependent on compiling for x86. Signed-off-by:
-
Andre Przywara authored
Both the 16550/8250 UART emulation in kvmtool as well as all the drivers and DTBs for real hardware use level triggered interrutpts. But the device tree currently describes them as being edge triggered, which can lead to hangs in guests. Use the new IRQ type parameter to properly describe the interrupts. This goes along the lines of a similar QEMU patch: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0be969a2d974971628fc4ed95834d22ecf0fd497 Signed-off-by:
-
Andre Przywara authored
Currently we describe every interrupt for each device in the FDT as being edge triggered. Add a parameter to the irq property generation to allow devices to specify their interrupts as level triggered if needed. Signed-off-by:
-
Andre Przywara authored
We had GIC specific defines for the IRQ type identifiers in kvmtool. But in fact the specification of being a level or edge interrupt is quite generic, with the GIC binding using the generic Linux defines. So lets replace the GIC specific #defines in favour of the more general names copied from Linux' include/linux/irq.h. Signed-off-by:
-
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:
-
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:
-
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:
-
