1. 09 Jun, 2017 10 commits
  2. 24 Apr, 2017 1 commit
  3. 17 Feb, 2017 1 commit
    • Will Deacon's avatar
      kvmtool: virtio-net: fix VIRTIO_NET_F_MRG_RXBUF usage in rx thread · 3fea89a9
      Will Deacon authored
      When merging virtio-net buffers using the VIRTIO_NET_F_MRG_RXBUF feature,
      the first buffer added to the used ring should indicate the total number
      of buffers used to hold the packet. Unfortunately, kvmtool has a number
      of issues when constructing these merged buffers:
        - Commit 5131332e3f1a ("kvmtool: convert net backend to support
          bi-endianness") introduced a strange loop counter, which resulted in
          hdr->num_buffers being set redundantly the first time round
        - When adding the buffers to the ring, we actually add them one-by-one,
          allowing the guest to see the header before we've inserted the rest
          of the data buffers...
        - ... which is made worse because we non-atomically increment the
          num_buffers count in the header each time we insert a new data buffer
      Consequently, the guest quickly becomes confused in its net rx code and
      the whole thing grinds to a halt. This is easily exemplified by trying
      to boot a root filesystem over NFS, which seldom succeeds.
      This patch resolves the issues by allowing us to insert items into the
      used ring without updating the index. Once the full payload has been
      added and num_buffers corresponds to the total size, we *then* publish
      the buffers to the guest.
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  4. 01 Feb, 2017 1 commit
  5. 20 Dec, 2016 1 commit
  6. 28 Nov, 2016 2 commits
  7. 18 Nov, 2016 4 commits
  8. 05 Nov, 2016 1 commit
  9. 09 Aug, 2016 1 commit
  10. 29 Jul, 2016 1 commit
  11. 15 Jun, 2016 1 commit
  12. 14 Jun, 2016 1 commit
  13. 09 Jun, 2016 1 commit
  14. 17 May, 2016 2 commits
  15. 18 Apr, 2016 1 commit
  16. 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>
  17. 11 Apr, 2016 4 commits
  18. 16 Mar, 2016 1 commit
  19. 11 Mar, 2016 1 commit
  20. 02 Mar, 2016 4 commits