1. 02 Nov, 2018 1 commit
    • Julien Thierry's avatar
      kvm: Do not pause already paused vcpus · 29f4ec31
      Julien Thierry authored
      
      
      With the following sequence:
      	kvm__pause();
      	kvm__continue();
      	kvm__pause();
      
      There is a chance that not all paused threads have been resumed, and the
      second kvm__pause will attempt to pause them again. Since the paused thread
      is waiting to own the pause_lock, it won't write its second pause
      notification. kvm__pause will be waiting for that notification while owning
      pause_lock, so... deadlock.
      
      Simple solution is not to try to pause thread that had not the chance to
      resume.
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      29f4ec31
  2. 14 Apr, 2016 1 commit
    • Will Deacon's avatar
      kvmtool: delegate exit/reboot responsibility to vcpu0 · e8cb90fb
      Will Deacon authored
      
      
      Our exit/reboot code is a bit of a mess:
      
        - Both kvm__reboot and kvm_cpu_exit send SIGKVMEXIT to running vcpus
        - When vcpu0 exits, the main thread starts executing destructors
          (exitcalls) whilst other vcpus may be running
        - The pause_lock isn't always held when inspecting is_running for
          a vcpu
      
      This patch attempts to fix these issues by restricting the exit/reboot
      path to vcpu0 and the main thread. In particular, a KVM_SYSTEM_EVENT
      will signal SIGKVMEXIT to vcpu0, which will join with the main thread
      and then tear down the other vcpus before invoking any destructor code.
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Tested-by: default avatarJulien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e8cb90fb
  3. 11 Apr, 2016 1 commit
  4. 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>
      2aa76b26
  5. 27 Oct, 2015 1 commit
  6. 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
      SYSTEM_OFF).
      
      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>
      0161ed77
  7. 01 Jun, 2015 34 commits
    • Anup Patel's avatar
      kvmtool: Handle exit reason KVM_EXIT_SYSTEM_EVENT · 5f9b016e
      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: default avatarPranavkumar Sawargaonkar <pranavkumar@linaro.org>
      Signed-off-by: default avatarAnup Patel <anup.patel@linaro.org>
      Reviewed-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      [will: removed useless prints]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5f9b016e
    • Marc Zyngier's avatar
      kvmtool: virtio: pass trapped vcpu to IO accessors · 4123ca55
      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: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      4123ca55
    • Marc Zyngier's avatar
      kvmtool: sample CPU endianness on virtio-mmio device reset · 19d98215
      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: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      19d98215
    • Marc Zyngier's avatar
      kvmtool: pass trapped vcpu to MMIO accessors · 9b735910
      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: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      9b735910
    • Sasha Levin's avatar
      kvm tools: remove global kvm object · 4346fd8f
      Sasha Levin authored
      
      
      This was ugly, and now we get rid of it.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      4346fd8f
    • Sasha Levin's avatar
      kvm tools: use init/exit where possible · 49a8afd1
      Sasha Levin authored
      
      
      Switch to using init/exit calls instead of the repeating call blocks in builtin-run.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      49a8afd1
    • Sasha Levin's avatar
      kvm tools: move kvm_cpus into struct kvm · df4239fb
      Sasha Levin authored
      
      
      There's no reason the array of guest specific vcpus is global. Move it into
      struct kvm.
      
      Also split up arch specific vcpu init from the generic code and call it from
      the kvm_cpu initializer.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      df4239fb
    • Sasha Levin's avatar
      kvm tools: remove redundancy between kvm_config and kvm · 809f088b
      Sasha Levin authored
      
      
      Remove some redundant members between struct kvm_config and struct kvm
      since options are now contained within struct kvm.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      809f088b
    • Asias He's avatar
      kvm tools: Do not run guest if it is stopped. · f9fdf5cd
      Asias He authored
      
      
      If the guest is stopped, there is no need to run it.
      This patch fixes this when running 'lkvm stop'.
      
         KVM_RUN failed: Bad address
      Signed-off-by: default avatarAsias He <asias.hejun@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      f9fdf5cd
    • Asias He's avatar
      kvm tools: Fix 'lkvm stop' when guest is pasued. · 8dd576f5
      Asias He authored
      
      
      Currently, 'lkvm stop' can not stop a pasued guest becasue
      guest is blocked on the pause_lock.
      
      This patch fixes it by un-pausing the guest before stops it.
      
      The pthread_kill() call is not needed.
      Signed-off-by: default avatarAsias He <asias.hejun@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      8dd576f5
    • Matt Evans's avatar
      kvm tools: Remove KVM_NR_CPUS · e2077857
      Matt Evans authored
      
      
      The KVM_NR_CPUS define is only really used to statically size the global
      kvm_cpus array, which can just as easily be allocated on startup.  There is
      some checking of the -c <nr cpus> value given against NR_CPUs but this is
      later again checked against a dynamically-determined limit from
      KVM_CAP_MAX_VCPUS anyway.  The hardwired limit is arbitrary and not strictly
      necessary.
      
      This patch removes the #define, replacing the statically-sized array with
      a malloc; the array is kvm->nrcpus+1 in size so that any iterator can halt
      at the end (this is done in kvm_cpu__reboot, which doesn't have access to
      a struct kvm* and therefore kvm->nrcpus).
      
      An unused #define in x86/mptable.c is also removed.
      Signed-off-by: default avatarMatt Evans <matt@ozlabs.org>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      e2077857
    • Sasha Levin's avatar
      kvm tools: Fix MMIO ordering problem cause due to coalescing · a7518f05
      Sasha Levin authored
      
      
      If we took a MMIO exit, the data in the coalesced ring should be processes
      before the data in the exit itself is processed.
      
      Doing it wrong (like we did so far) will cause ordering issues.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      a7518f05
    • Matt Evans's avatar
      kvm tools: Create arch-specific kvm_cpu__emulate_{mm}io() · 17edd536
      Matt Evans authored
      
      
      Different architectures will deal with MMIO exits differently.  For example,
      KVM_EXIT_IO is x86-specific, and I/O cycles are often synthesised by steering
      into windows in PCI bridges on other architectures.
      
      This patch calls arch-specific kvm_cpu__emulate_io() and kvm_cpu__emulate_mmio()
      from the main runloop's IO and MMIO exit handlers.  For x86, these directly
      call kvm__emulate_io() and kvm__emulate_mmio() but other architectures will
      perform some address munging before passing on the call.
      Signed-off-by: default avatarMatt Evans <matt@ozlabs.org>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      17edd536
    • Sasha Levin's avatar
      kvm tools: Add NMI ability to 'kvm debug' · 4b1c6f6e
      Sasha Levin authored
      
      
      This allows triggering NMI on guests using 'kvm debug -m [cpu]'.
      
      Please note that the default behaviour of 'kvm debug' dumping guest's cpu
      state has been modified to require a '-d'/--dump.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      4b1c6f6e
    • Matt Evans's avatar
      kvm tools: Fix KVM_RUN exit code check · 76b75d32
      Matt Evans authored
      
      
      kvm_cpu__run() currently die()s if KVM_RUN returns non-zero.  Some architectures
      may return positive values in non-error cases, whereas real errors are always
      negative return values.  Check for those instead.
      Signed-off-by: default avatarMatt Evans <matt@ozlabs.org>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      76b75d32
    • Matt Evans's avatar
      kvm tools: Add arch-specific KVM_RUN exit handling via kvm_cpu__handle_exit() · 341ee0d4
      Matt Evans authored
      
      
      This patch creates a new function in x86/kvm-cpu.c, kvm_cpu__handle_exit(), in
      which arch-specific exit reasons can be handled outside of the common runloop.
      Signed-off-by: default avatarMatt Evans <matt@ozlabs.org>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      341ee0d4
    • Matt Evans's avatar
      kvm tools: Split x86 arch-specific bits into x86/ · af7b0868
      Matt Evans authored
      
      
      Create a new arch-specific subdirectory to contain architecture-specific code
      and includes.
      
      The Makefile now adds various arch-specific objects based on detected
      architecture.  That aside, this patch should only contain code moves.  These
      include:
      
      - x86-specific kvm_cpu setup, kernel loading, memory setup etc. now in
        x86/kvm{-cpu}.c
      - BIOS now lives in x86/bios/
      - ioport setup
      - KVM extensions are asserted in arch-specific kvm.c now, so each architecture
        can manage its own dependencies.
      - Various architecture-specific #defines are moved into $(ARCH)/include/kvm{-cpu}.h
        such as struct kvm_cpu, KVM_NR_CPUS, KVM_32BIT_GAP_SIZE.
      Signed-off-by: default avatarMatt Evans <matt@ozlabs.org>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      af7b0868
    • Sasha Levin's avatar
      kvm tools: Allow piping debug output to file descriptor · b7d2f013
      Sasha Levin authored
      
      
      This patch makes debug output go to a 'debug_fd' instead of stdout.
      
      Doing so allows us to send the output to a different console when
      required.
      
      This patch also changes the behaviour of 'kvm debug' to show the debug
      output in the console that executed the debug command instead of in the
      console of the guest.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      b7d2f013
    • Sasha Levin's avatar
      kvm tools: Enable fast string operations · f7054059
      Sasha Levin authored
      
      
      Recent kernels check for MSR_IA32_MISC_ENABLE_FAST_STRING in the
      MSR_IA32_MISC_ENABLE MSR before enabling reps/movs memcpy.
      
      So far we didn't set it, and got a slower memcpy and a warning:
      
      	[    0.000000] Disabled fast string operations
      
      This patch enables fast string operations.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      f7054059
    • Sasha Levin's avatar
      kvm tools: Make keyboard termination go through regular termination path · c23d9748
      Sasha Levin authored
      
      
      Instead of exiting directly when a user enters 'ctrl x + a', go through
      the regular termination path by stopping all VCPUs and letting the
      main thread handle it.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      c23d9748
    • Pekka Enberg's avatar
      kvm tools: Fix guest single-stepping setup · 6d6a4d41
      Pekka Enberg authored
      
      
      "K. Watts" writes:
      
        When the singlestep is enabled the ioctl to sent out when the kvm_cpu
        is initialized (kvm-cpu.c in the for loop that gets each vcpu built).
        When the ioct goes out the CPU is sitting at the initialization vector
        of 0xf000:0xfff0 on CPU #0 and 0x000000 on the other SMP CPUs.  The
        new host kernel code that handles setting the TF was changed in 2.6.32
        and again at 2.6.38.  2.6.32 seems just flat broken, but 2.6.38 checks
        that the linear address of the RIP matches what it was when the
        KVM_GUESTDBG_SINGLESTEP flag was set.  Because the kvm-tool doesn't
        start the CPU at the initialization vector (0xfff0) (0x7c00 for the
        MBR and where ever you guys map the linux kernel to) they don't match
        and the host kernel won't set the trap flag.
      
        Basically the debug and singlestep ioclts need to happen after the CPU
        has been initialized.  I moved kvm_cpu__enable_singlestep to happen in
        kvm_cpu__reset_vcpu after the registers are set (EIP points to boot
        address) and the TRAP flags get set and all is good with the world.
      
        Singlestepping is disabled when the guest issues a CLI because the
        Linux host doesn't support features in new Intel and AMD CPUs.  We can
        sort of "shadow" the interrupt mask and still get the CPU to trap out
        at ever instruction even when the guest has disabled interrupts on the
        CPU.  I have to get the bios disk handler working completely first,
        but that may be my next task so that we can trace all the CPU
        instructions.  My current hack is to just re-enable the trap flag
        every time a VMEXIT occurs.  I get enough instructions to get me by.
      
      This patch fixes the problem by moving the kvm_cpu__enable_singlestep() into
      kvm_cpu__start().
      Suggested-by: default avatarK. Watts <traetox@gmail.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      6d6a4d41
    • Sasha Levin's avatar
      kvm tools: Implement keyboard reset method · 714e5b7f
      Sasha Levin authored
      
      
      Implement the keyboard reset method which allows guest kernel
      to reboot the guest using the keyboard controller.
      
      This will allow guest kernel to reboot the guest when it needs to,
      for example - kernel panic (when passing "panic=1" as kernel parameter).
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      714e5b7f
    • Sasha Levin's avatar
      kvm tools: Add MMIO coalescing support · 73f7e5b3
      Sasha Levin authored
      
      
      Coalescing MMIO allows us to avoid an exit every time we have a
      MMIO write, instead - MMIO writes are coalesced in a ring which
      can be flushed once an exit for a different reason is needed.
      A MMIO exit is also trigged once the ring is full.
      
      Coalesce all MMIO regions registered in the MMIO mapper.
      Add a coalescing handler under kvm_cpu.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      73f7e5b3
    • Sasha Levin's avatar
      kvm tools: Add APIs to allow pausing guests · 4298ddad
      Sasha Levin authored
      
      
      Allow pausing and unpausing guests running on the host.
      Pausing a guest means that none of the VCPU threads are running
      KVM_RUN until they are unpaused.
      
      The following API functions are added:
       void kvm__pause(void);
       void kvm__continue(void);
       void kvm__notify_paused(void);
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      4298ddad
    • Sasha Levin's avatar
      kvm tools: Exit VCPU thread only when SIGKVMEXIT is received · 656be1b8
      Sasha Levin authored
      
      
      Currently the VCPU loop would exit when the thread received any signal.
      
      Change behaviour to exit only when SIGKVMEXIT is received. This change
      prevents from the guest to terminate when unrelated signals are processed
      by the thread (for example, when attaching a debugger).
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      656be1b8
    • Sasha Levin's avatar
      kvm tools: Exit properly on SMP guests · 49e5227d
      Sasha Levin authored
      
      
      When shutting down SMP guests only VCPU #0 will receive
      a KVM_EXIT_SHUTDOWN. Waiting for all VCPU threads to exit
      causes them to hang.
      
      Instead, notify all VCPU threads once VCPU #0 thread is terminated
      so they could also stop properly.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      49e5227d
    • Cyrill Gorcunov's avatar
      kvm tools: Prefix error() and friends helpers with pr_ · 4542f276
      Cyrill Gorcunov authored
      
      
      To look more familiar with kernel functions.
      Suggested-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@gmail.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      4542f276
    • Pekka Enberg's avatar
      kvm tools: Lookup symbol based on RIP for 'kill -3' · b0b42ba0
      Pekka Enberg authored
      
      
      To make debugging easier, look up symbol from guest kernel image based on RIP
      when user does 'kill -3' to the hypervisor.
      
      Example output looks as follows:
      
        Code:
        -----
        rip: [<ffffffff812cb3a0>] delay_loop+30 (/home/penberg/linux/arch/x86/lib/delay.c:32)
      
      Cc: Asias He <asias.hejun@gmail.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Prasad Joshi <prasadjoshi124@gmail.com>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      b0b42ba0
    • Sasha Levin's avatar
    • Sasha Levin's avatar
      kvm tools: Rename 'self' variables · 43835ac9
      Sasha Levin authored
      
      
      Give proper names to vars named 'self'.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      43835ac9
    • Ingo Molnar's avatar
      kvm tools: Fix and improve the CPU register dump debug output code · b5b501cc
      Ingo Molnar authored
      
      
      * Pekka Enberg <penberg@kernel.org> wrote:
      
      > Ingo Molnar reported that 'kill -3' didn't work on his machine:
      >
      >   * Ingo Molnar <mingo@elte.hu> wrote:
      >
      >   > This is really cumbersome to debug - is there some good way to get to the RIP
      >   > that the guest is hanging in? If kvm would print that out to the host console
      >   > (even if it's just the raw RIP initially) on a kill -3 that would help
      >   > enormously.
      >
      >   Looks like the code should be doing that already - but the ioctl(KVM_GET_SREGS)
      >   hangs:
      >
      >     [pid   748] ioctl(6, KVM_GET_SREGS
      >
      > Avi Kivity pointed out that it's not safe to call KVM_GET_SREGS (or other vcpu
      > related ioctls) from other threads:
      >
      >   > is it not OK to call KVM_GET_SREGS from other threads than the one
      >   > that's doing KVM_RUN?
      >
      >   From Documentation/kvm/api.txt:
      >
      >    - vcpu ioctls: These query and set attributes that control the operation
      >      of a single virtual cpu.
      >
      >      Only run vcpu ioctls from the same thread that was used to create the
      >      vcpu.
      >
      > Fix that up by using pthread_kill() to force the threads that are doing KVM_RUN
      > to do the register dumps.
      >
      > Reported: Ingo Molnar <mingo@elte.hu>
      > Cc: Asias He <asias.hejun@gmail.com>
      > Cc: Avi Kivity <avi@redhat.com>
      > Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      > Cc: Ingo Molnar <mingo@elte.hu>
      > Cc: Prasad Joshi <prasadjoshi124@gmail.com>
      > Cc: Sasha Levin <levinsasha928@gmail.com>
      > Signed-off-by: Pekka Enberg <penberg@kernel.org>
      > ---
      >  tools/kvm/kvm-run.c |   20 +++++++++++++++++---
      >  1 files changed, 17 insertions(+), 3 deletions(-)
      >
      > diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
      > index eb50b6a..58e2977 100644
      > --- a/tools/kvm/kvm-run.c
      > +++ b/tools/kvm/kvm-run.c
      > @@ -127,6 +127,18 @@ static const struct option options[] = {
      >  	OPT_END()
      >  };
      >
      > +static void handle_sigusr1(int sig)
      > +{
      > +	struct kvm_cpu *cpu = current_kvm_cpu;
      > +
      > +	if (!cpu)
      > +		return;
      > +
      > +	kvm_cpu__show_registers(cpu);
      > +	kvm_cpu__show_code(cpu);
      > +	kvm_cpu__show_page_tables(cpu);
      > +}
      > +
      >  static void handle_sigquit(int sig)
      >  {
      >  	int i;
      > @@ -134,9 +146,10 @@ static void handle_sigquit(int sig)
      >  	for (i = 0; i < nrcpus; i++) {
      >  		struct kvm_cpu *cpu = kvm_cpus[i];
      >
      > -		kvm_cpu__show_registers(cpu);
      > -		kvm_cpu__show_code(cpu);
      > -		kvm_cpu__show_page_tables(cpu);
      > +		if (!cpu)
      > +			continue;
      > +
      > +		pthread_kill(cpu->thread, SIGUSR1);
      >  	}
      >
      >  	serial8250__inject_sysrq(kvm);
      
      i can see a couple of problems with the debug printout code, which currently
      produces a stream of such dumps for each vcpu:
      
      Registers:
       rip: 0000000000000000   rsp: 00000000000016ca flags: 0000000000010002
       rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000000
       rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
       rbp: 0000000000008000   r8:  0000000000000000   r9:  0000000000000000
       r10: 0000000000000000   r11: 0000000000000000   r12: 0000000000000000
       r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
       cr0: 0000000060000010   cr2: 0000000000000070   cr3: 0000000000000000
       cr4: 0000000000000000   cr8: 0000000000000000
      Segment registers:
       register  selector  base              limit     type  p dpl db s l g avl
       cs        f000      00000000000f0000  0000ffff  03    1 3   0  1 0 0 0
       ss        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       ds        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       es        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       fs        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       gs        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       tr        0000      0000000000000000  0000ffff  0b    1 0   0  0 0 0 0
       ldt       0000      0000000000000000  0000ffff  02    1 0   0  0 0 0 0
       gdt                 0000000000000000 0000ffff
       idt                 0000000000000000 0000ffff
       [ efer: 0000000000000000  apic base: 00000000fee00900  nmi: enabled ]
      Interrupt bitmap:
       0000000000000000 0000000000000000 0000000000000000 0000000000000000
      Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <cf> eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 f6 c4 0e 75 4b
      Stack:
        0x000016ca: 00 00 00 00  00 00 00 00
        0x000016d2: 00 00 00 00  00 00 00 00
        0x000016da: 00 00 00 00  00 00 00 00
        0x000016e2: 00 00 00 00  00 00 00 00
      
      The problems are:
      
       - This does not work very well on SMP with lots of vcpus, because the printing
         is unserialized, resulting in a jumbled mess of an output, all vcpus trying
         to print to the console at once, often mixing lines and characters randomly.
      
       - stdout from a signal handler must be flushed, otherwise lines can remain
         buffered if someone saves the output via 'tee' for example.
      
       - the dumps from the various CPUs are not distinguishable - they are just
         dumped after each other with no identification
      
       - the various printouts are rather hard to parse visually - it's not easy to see
         various properties "at a glance" because the dump is visually confusing.
      
      The patch below addresses these concerns, serializes the output, tidies up the
      printout, resulting in this new output:
      
      #
      # vCPU #0's dump:
      #
      
       Registers:
       ----------
       rip: 0000000000000000   rsp: 00000000000008bc flags: 0000000000010002
       rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000000
       rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
       rbp: 0000000000008000    r8: 0000000000000000    r9: 0000000000000000
       r10: 0000000000000000   r11: 0000000000000000   r12: 0000000000000000
       r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
       cr0: 0000000060000010   cr2: 0000000000000070   cr3: 0000000000000000
       cr4: 0000000000000000   cr8: 0000000000000000
      
       Segment registers:
       ------------------
       register  selector  base              limit     type  p dpl db s l g avl
       cs        f000      00000000000f0000  0000ffff  03    1 3   0  1 0 0 0
       ss        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       ds        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       es        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       fs        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       gs        1000      0000000000010000  0000ffff  03    1 3   0  1 0 0 0
       tr        0000      0000000000000000  0000ffff  0b    1 0   0  0 0 0 0
       ldt       0000      0000000000000000  0000ffff  02    1 0   0  0 0 0 0
       gdt                 0000000000000000  0000ffff
       idt                 0000000000000000  0000ffff
      
       APIC:
       -----
       efer: 0000000000000000  apic base: 00000000fee00900  nmi: enabled
      
       Interrupt bitmap:
       -----------------
       0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
       Code:
       -----
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <cf> eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 f6 c4 0e 75 4b
      
       Stack:
       ------
        0x000008bc: 00 00 00 00  00 00 00 00
        0x000008c4: 00 00 00 00  00 00 00 00
        0x000008cc: 00 00 00 00  00 00 00 00
        0x000008d4: 00 00 00 00  00 00 00 00
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      b5b501cc
    • Sasha Levin's avatar
      kvm tools: Enable SMP support · 1621292e
      Sasha Levin authored
      
      
      This patch enables SMP support:
      
      [    0.155072] Brought up 3 CPUs
      [    0.155074] Total of 3 processors activated (15158.58 BogoMIPS).
      
      virtio-console was being loaded no matter the cmdline options
      and it was causing some hangs (have to look into that).
      
      I'll send this patch to a larger audience once someone
      else can confirm it actually works/doesn't work.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      1621292e
    • Sasha Levin's avatar
      kvm tools: Abolishment of uint*_t types · 3fdf659d
      Sasha Levin authored
      
      
      Clean uint*_t type from the code.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      3fdf659d
    • Cyrill Gorcunov's avatar
      kvm tools: Use system wide msr-index.h instead of own definitions · 62219c71
      Cyrill Gorcunov authored
      
      
      To eliminate code duplication.
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      62219c71