- Feb 13, 2015
-
-
Andre Przywara authored
kvmtool used the in-kernel version of the device tree handling library. Now that we are a proper userland tool, use the system's library for that purpose. Actually this seems to fix some long-standing warning generated by the Linux copy. Fix up a bogus x86 warning (no FDT needed here). Signed-off-by:Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
In config/utilities.mak we have two macros checking either compile-ability or build-ability of a library. Actually they are defined the same, with try-cc behaving like try-build for no reason. Fix try-cc to really only test compilation (no linking) and replace all calls to try-cc in the Makefile with try-build (as this is what we need). Simplify the Makefile calls a bit on the way. Signed-off-by: -
Andre Przywara authored
This header isn't actually a uapi header, but we need it, so copy it in for the time being. Signed-off-by: -
Andre Przywara authored
Some distributions with an older uapi header copy do not have these (applies to Ubuntu 12.04, for instance). Signed-off-by: -
Andre Przywara authored
The kernel uses separate types for uid_t and gid_t and kvmtool somehow inherited these instead of the POSIX versions. (WHY?) Signed-off-by: -
Andre Przywara authored
Signed-off-by: -
Andre Przywara authored
The special Linux poison bits do not make sense in userland, so just replace them with NULL to spot bogus accesses. Signed-off-by: -
Andre Przywara authored
Signed-off-by: -
Andre Przywara authored
Signed-off-by: -
Andre Przywara authored
The /usr/include/linux copy of kvm.h is usually outdated, so copy over a fresh copy from the 3.18.0 source tree. This mimics QEMU's behaviour. Signed-off-by: -
Andre Przywara authored
Instead of moving the whole include file in, 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. 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
Signed-off-by: -
Andre Przywara authored
Signed-off-by:
-
- Jan 24, 2015
-
-
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:
Will Deacon <will.deacon@arm.com> Signed-off-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:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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: -
Fix trivial overflow of u32 value Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
Pekka Enberg <penberg@kernel.org>
-
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:
-
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:
-
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:
-
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:
-
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:
-
Signed-off-by:
-
It doesn't work on big endian hosts as is. Signed-off-by:
-
Signed-off-by:
-
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:
-
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:
-
... to get rid of its function definition from archs that don't support it. Signed-off-by:
-
