1. 02 Mar, 2016 1 commit
  2. 01 Feb, 2016 1 commit
  3. 18 Nov, 2015 7 commits
  4. 11 Nov, 2015 1 commit
  5. 09 Nov, 2015 1 commit
    • Andre Przywara's avatar
      kvmtool: Makefile: remove LDFLAGS from guest_init linking · b40a51a1
      Andre Przywara authored
      Looking back at the HEAD from a few commits ago, it's obvious that
      using the LDFLAGS variable for linking the guest_init binary was
      rather pointless, as it was zeroed in the beginning and then never
      As guest_init is a rather special binary that does not cope well with
      arbitrary linker flags, let's reinstantiate the previous state by
      removing the LDFLAGS variable from those linking steps. This allows
      LDFLAGS to be used for linking the actual kvmtool binary only and
      helps to re-merge commit d0e2772b
       ("Makefile: allow overriding
      CFLAGS on the command line").
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  6. 05 Nov, 2015 1 commit
    • Will Deacon's avatar
      kvmtool: fix VM exit race attempting to pthread_kill an exited thread · 2aa76b26
      Will Deacon authored
      lkvm currently suffers from a Segmentation Fault when exiting, which can
      also lead to the console not being cleaned up correctly after a VM exits.
      The issue is that (the misnamed) kvm_cpu__reboot function sends a
      SIGKVMEXIT to each vcpu thread, which causes those vcpu threads to exit
      once their main loops (kvm_cpu__start) detect that cpu->is_running is
      now false. The lack of synchronisation in this exit path means that a
      concurrent pause event (due to the br_write_lock in ioport__unregister)
      ends up sending SIGKVMPAUSE to an exited thread, resulting in a SEGV.
      This patch fixes the issue by moving kvm_cpu__reboot into kvm.c
      (renaming it in the process) where it can hold the pause_lock mutex
      across the reboot operation. This in turn makes it safe for the pause
      code to check the is_running field of each CPU before attempting to
      send a SIGKVMPAUSE signal.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  7. 04 Nov, 2015 1 commit
  8. 02 Nov, 2015 3 commits
    • Andre Przywara's avatar
      Makefile: consider LDFLAGS on feature tests and when linking executables · 03c49af7
      Andre Przywara authored
      While we have an LDFLAGS variable in kvmtool's Makefile, it's not
      really used when both doing the feature tests and when finally linking
      the lkvm executable.
      Add that variable to all the linking steps to allow the user to
      specify custom library directories or linker options on the command
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Andre Przywara's avatar
      Makefile: allow overriding CFLAGS on the command line · d0e2772b
      Andre Przywara authored
      When a Makefile variable is set on the make command line, all
      Makefile-internal assignments to that very variable are _ignored_.
      Since we add quite some essential values to CFLAGS internally,
      specifying some CFLAGS on the command line will usually break the
      build (and not fix any include file problems you hoped to overcome
      with that).
      Somewhat against intuition GNU make provides the "override" directive
      to change this behavior; with that assignments in the Makefile get
      _appended_ to the value given on the command line. [1]
      Change any internal assignments to use that directive, so that a user
      can use:
      $ make CFLAGS=/path/to/my/include/dir
      to teach kvmtool about non-standard header file locations (helpful
      for cross-compilation) or to tweak other compiler options.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      [1] https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • William Dauchy's avatar
      kvmtool/run: set a default cmdline if not set · d583df25
      William Dauchy authored
      when starting with custom kernel and disk options, kernel_cmdline is
      NULL; it results in a segfault while trying to look for a string
      using `strstr`:
      __strstr_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:40
      0x00000000004056bf in kvm_cmd_run_init (argc=<optimized out>, argv=<optimized out>) at builtin-run.c:608
      0x000000000040639d in kvm_cmd_run (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>) at builtin-run.c:659
      0x0000000000412b8f in handle_command (command=0x62bbc0 <kvm_commands>, argc=5, argv=0x7fffffffe840) at kvm-cmd.c:84
      0x00007ffff7211b45 in __libc_start_main (main=0x403540 <main>, argc=6, argv=0x7fffffffe838, init=<optimized out>, fini=<optimized out>,
        rtld_fini=<optimized out>, stack_end=0x7fffffffe828) at libc-start.c:287
      0x0000000000403962 in _start ()
      this patch suggests to set a minimal cmdline when kernel_cmdline is NULL
      Fixes: 8a7163f3
       ("kvmtool/run: append cfg.kernel_cmdline at the end of real_cmdline")
      Signed-off-by: default avatarWilliam Dauchy <william@gandi.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  9. 28 Oct, 2015 1 commit
  10. 27 Oct, 2015 9 commits
  11. 09 Oct, 2015 1 commit
  12. 15 Sep, 2015 1 commit
  13. 10 Sep, 2015 1 commit
  14. 04 Sep, 2015 1 commit
    • Mark Rutland's avatar
      Handle KVM_EXIT_SYSTEM_EVENT on any VCPU · 0161ed77
      Mark Rutland authored
      When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends
      SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down
      any remaining context. The signalling of SIGKVMEXIT is critical to
      forcing VCPUs to shut down in response to a system event (e.g. PSCI
      VCPUs other that VCPU #0 simply exit in kvm_cpu_thread without forcing
      other CPUs to shut down. Thus if a system event is taken on a VCPU other
      than VCPU #0, the remaining CPUs are left online. This results in KVM
      tool not exiting as expected when a system event is taken on a VCPU
      other than VCPU #0 (as may happen if the guest panics).
      Fix this by tearing down all CPUs upon a system event, regardless of the
      CPU on which the event occurred. While this means the VCPU thread will
      signal itself, and VCPU #0 will signal all other VCPU threads a second
      time, these are harmless.
      Signed-off-by: Mark Rutland's avatarMark Rutland <mark.rutland@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Suzuki Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  15. 07 Aug, 2015 3 commits
  16. 06 Aug, 2015 1 commit
  17. 22 Jul, 2015 2 commits
  18. 20 Jul, 2015 4 commits