1. 19 Jun, 2018 1 commit
  2. 23 May, 2018 3 commits
  3. 06 Apr, 2018 3 commits
  4. 19 Mar, 2018 2 commits
    • Jean-Philippe Brucker's avatar
      virtio: Clean up next_desc · bbea6c7a
      Jean-Philippe Brucker authored
      
      
      The wmb() in next_desc seems out of place and the comments are
      inaccurate. Remove the unnecessary barrier and clean up next_desc().
      
      next_desc() is called by virt_queue__get_head_iov() when filling the iov
      with desciptor addresses. It reads the descriptor's flag and next index.
      The virt_queue__get_head_iov() only reads the direct and indirect
      descriptors, and doesn't write any shared memory except from iov and
      cursors that will be read by the caller.
      
      As far as I can see, vhost (the kernel implementation of virtio device)
      does well without any barrier here, so I think it might be safe to remove.
      
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      bbea6c7a
    • Jean-Philippe Brucker's avatar
      virtio: Fix ordering of avail index and descriptor read · 15c4e1ef
      Jean-Philippe Brucker authored
      
      
      One barrier seems to be missing from kvmtool's virtio implementation,
      between virt_queue__available() and virt_queue__pop(). In the following
      scenario "avail" represents the shared "available" structure in the virtio
      queue:
      
                     Guest               |               Host
                                         |
          avail.ring[shadow] = desc_idx  | while (avail.idx != shadow)
          smp_wmb()                      |     /* missing smp_rmb() */
          avail.idx = ++shadow           |     desc_idx = avail.ring[shadow++]
      
      If the host observes the avail.idx write before the avail.ring update,
      then it will fetch the wrong desc_idx. Add the missing barrier.
      
      This seems to fix the horrible bug I'm often seeing when running netperf
      in a guest (virtio-net + tap) on AMD Seattle. The TX thread reads the
      wrong descriptor index and either faults when accessing the TX buffer, or
      pushes the wrong index to the used ring. In that case the guest complains
      that "id %u is not a head!" and stops the queue.
      
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      15c4e1ef
  5. 29 Jan, 2018 3 commits
    • Jean-Philippe Brucker's avatar
      virtio/pci: Use port I/O for configuration registers by default · a508ea95
      Jean-Philippe Brucker authored
      Modern virtio PCI is allowed to use both memory and I/O BARs for the
      config space, but legacy devices must use I/O for BAR0, as specified by
      Virtio v1.0 cs04:
      
      4.1.5.1.1.1 Legacy Interface: A Note on Device Layout Detection
      "Transitional devices MUST expose the Legacy Interface in I/O space in
      BAR0."
      
      What virtio calls "I/O space" is most certainly port I/O, as hinted by the
      discussion in 4.1.4 Virtio Structure PCI Capabilities, where it
      distinguishes "memory BARs" from "I/O BARs". This is also the conclusion
      made by SeaBIOS [1], which only looks for port I/O in BAR0 when driving a
      transitional device.
      
      I think MMIO was made the default by a463650c ("kvm tools: pci: add
      MMIO interface to virtio-pci devices") to support ARM targets, but we
      support PIO as well as MMIO nowadays. So let's make the legacy virtio
      implementation comply with the specification and use port I/O for BAR0.
      
      [1] https://patchwork.kernel.org/patch/10038927/
      
      
      
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      a508ea95
    • Jean-Philippe Brucker's avatar
      virtio: Support drivers that don't negotiate VIRTIO_RING_F_EVENT_IDX · b7af514c
      Jean-Philippe Brucker authored
      Bad things happen when the VIRTIO_RING_F_EVENT_IDX feature isn't
      negotiated and we try to write the avail_event anyway. SeaBIOS, for
      example, stores internal data where avail_event should be [1].
      
      Technically the Virtio specification doesn't forbid the device from
      writing the avail_event, and it's up to the driver to reserve space for it
      ("the transitional driver [...] MUST allocate the total number of bytes
      for the virtqueue according to [formula containing the avail event]").
      
      But it doesn't hurt us to avoid writing avail_event, and kvmtool needs
      changes for interrupt suppression anyway, in order to comply with the
      spec. Indeed Virtio 1.0 cs04 says, in 2.4.7.2 Device Requirements:
      Virtqueue Interrupt Suppression:
      """
      If the VIRTIO_F_EVENT_IDX feature bit is not negotiated:
      * The device MUST ignore the used_event value.
      * After the device writes a descriptor index into the used ring:
        - If flags is 1, the device SHOULD NOT send an interrupt.
      """
      
      So let's do that.
      
      [1] https://patchwork.kernel.org/patch/10038931/
      
      
      
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      b7af514c
    • Jean-Philippe Brucker's avatar
      virtio: Save negotiated features · 56a16c90
      Jean-Philippe Brucker authored
      
      
      We're going to need the features bits negotiated between host and guest in
      the core code. Save them in the virtio_device structure.
      
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      56a16c90
  6. 14 Dec, 2017 1 commit
  7. 03 Nov, 2017 4 commits
  8. 25 Oct, 2017 1 commit
  9. 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
  10. 09 Oct, 2017 1 commit
  11. 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
  12. 09 Jun, 2017 16 commits