1. 29 Jan, 2018 1 commit
  2. 14 Dec, 2017 1 commit
  3. 03 Nov, 2017 4 commits
  4. 25 Oct, 2017 1 commit
  5. 24 Oct, 2017 1 commit
    • Wei Chen's avatar
      arm: Allow all terminal ports to be bi-directional · 83042d1e
      Wei Chen authored
      
      
      In kvmtool, the terminal has 4 term-devices at most. And these term-devices
      can connect to serial8250 or virtio console ports. The kvmtool has a loop
      thread to detect the incoming data on these term-devices and then send the
      data to guest through serial8250 or virtio console ports. On x86, kvmtool
      allow to read data from all 4 term-devices. But on ARM, we only support reading
      data from the first term-devices. The data from the other term-devices will
      be ignored.
      
      Currently, we're adding the kvmtool support to runv (a kind of hyper container)
      with Hyperhq guys. Here we're using 3 serial ports in guest to communicate with
      host (Container runtime). On x86, it works fine, but on ARM it could not work.
      Because we're using terminal 2 to send/receive control message, but terminal 2
      is single direction.
      
      In this case, we change the kvm__arch_read_term for ARM to allow reading data
      from all term-devices.
      
      Signed-off-by: default avatarWei Chen <Wei.Chen@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      83042d1e
  6. 09 Oct, 2017 1 commit
  7. 30 Aug, 2017 4 commits
    • Marc Zyngier's avatar
      Makefile: avoid using linker for embedding guest_init binaries · 93dd1288
      Marc Zyngier authored
      
      
      At the moment we use the linker to convert the compiled guest_init binary
      into an ELF object file, so it can be embedded into the kvmtool binary
      and accessed later easily at runtime.
      Now this has two problems:
      1) This approach does not work for MIPS, because the linker defaults to
      a different ABI than the compiler, so the GCC generated object files are
      not compatible with this converted binary.
      2) The size symbol as it's used at the moment in the object file is subject
      to relocation, which leads to wrong results when using PIE builds, which is
      now the default for some distributions.
      
      Fix those two problems at once by using some shell tools to create a C
      source file containing the guest_init binary, which then gets compiled into
      a proper object file with the normal compiler and its flags.
      The size of the guest init binaries is now simply a variable, which does
      not get mangled at all.
      
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      93dd1288
    • Andre Przywara's avatar
      Makefile: properly express guest_init dependency · 23a9388e
      Andre Przywara authored
      
      
      So far the generation of the guest_init binaries is not properly
      modelled in the Makefile: the intermediate object files are not targets.
      This leads to failures when those files get deleted.
      So (also in preperation for the upcoming rework) rework the dependency
      chain to have those intermediate files covered as well, which involves
      splitting the generation into two steps.
      On the way use automatic variables where applicable and remove the
      explicit listing of the guest_init targets, which are now covered by
      the final $(GUEST_OBJS) targets.
      
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      23a9388e
    • Wei Chen's avatar
      net: Check UFO offloading support for tap driver · 59ee54eb
      Wei Chen authored
      In Linux commit fb652fdfe83710da0ca13448a41b7ed027d0a984:
      https://www.spinics.net/lists/netdev/msg443562.html
      
      
      The UFO support had been removed.
      
      If we use tap mode for network (--network mode=tap,tapif=...),
      we will get following error:
      "Warning: Config tap device TUNSETOFFLOAD error
       You have requested a TAP device,
       but creation of one has failed because: Invalid argument"
      
      So, if we're running with latest kernel, we'd better to remove
      TUN_F_UFO from TAP init. But if we're running with older kernels
      without above commit. We'll miss the UFO feature. In this case,
      we'd better to check the kernel UFO support status for tap driver.
      
      The tap UFO state will used in get_host_features to return correct
      VIRTIO_NET features. If we defer the tap UFO support check in
      virtio_net__tap_init, it will be too later. So we separate the
      tap create code from tap_init to a standalone function. This new
      function will be used in virtio_net_init to create tap device and
      check the tap UFO support status at the very beginning.
      
      Signed-off-by: default avatarWei Chen <Wei.Chen@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      59ee54eb
    • Thomas Petazzoni's avatar
      x86/kvm-cpu.c: don't include <asm/msr-index.h> · 1cc05b24
      Thomas Petazzoni authored
      
      
      Since kernel commit 25dc1d6cc3082aab293e5dad47623b550f7ddd2a ("x86:
      stop exporting msr-index.h to userland"), <asm/msr-index.h> is no
      longer exported to userspace. Therefore, any toolchain built with
      kernel headers >= 4.12 will no longer have this header file, causing a
      build failure in kvmtool.
      
      As a replacement, this patch includes inside x86/kvm-cpu.c the
      necessary MSR_* definitions.
      
      Reviewed-by: default avatarRiku Voipio <riku.voipio@linaro.org>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1cc05b24
  8. 09 Jun, 2017 17 commits
  9. 24 Apr, 2017 1 commit
  10. 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>
      3fea89a9
  11. 01 Feb, 2017 1 commit
  12. 20 Dec, 2016 1 commit
  13. 28 Nov, 2016 2 commits
  14. 18 Nov, 2016 4 commits