1. 22 Nov, 2019 4 commits
  2. 25 Oct, 2019 1 commit
  3. 02 Aug, 2019 1 commit
  4. 03 Jul, 2019 4 commits
  5. 10 Jun, 2019 2 commits
    • Andre Przywara's avatar
      run: Check for ghost socket file upon VM creation · ef5b941f
      Andre Przywara authored
      
      
      Kvmtool creates a (debug) UNIX socket file for each VM, using its
      (possibly auto-generated) name as the filename. There is a check using
      access(), which bails out with an error message if a socket with that
      name already exists.
      
      Aside from this check being unnecessary, as the bind() call later would
      complain as well, this is also racy. But more annoyingly the bail out is
      not needed most of the time: an existing socket inode is most likely just
      an orphaned leftover from a previous kvmtool run, which just failed to
      remove that file, because of a crash, for instance.
      
      Upon finding such a collision, let's first try to connect to that socket,
      to detect if there is still a kvmtool instance listening on the other
      end. If that fails, this socket will never come back to life, so we can
      safely clean it up and reuse the name for the new guest.
      However if the connect() succeeds, there is an actual live kvmtool
      instance using this name, so not proceeding is the only option.
      This should never happen with the (PID based) automatically generated
      names, though.
      
      This avoids an annoying (and not helpful) error message and helps
      automated kvmtool runs to proceed in more cases.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ef5b941f
    • Andre Przywara's avatar
      list: Clean up ghost socket files · 67f9f7b7
      Andre Przywara authored
      
      
      When kvmtool (or the host kernel) crashes or gets killed, we cannot
      automatically remove the socket file we created for that VM.
      A later call of "lkvm list" iterates over all those files and complains
      about those "ghost socket files", as there is no one listening on
      the other side. Also sometimes the automatic guest name generation
      happens to generate the same name again, so an unrelated "lkvm run"
      later complains and stops, which is bad for automation.
      
      As the only code doing a listen() on this socket is kvmtool upon VM
      *creation*, such an orphaned socket file will never come back to life,
      so we can as well unlink() those sockets in the code. This spares the
      user from doing it herself.
      We keep the message in the code to notify the user of this.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      67f9f7b7
  6. 29 May, 2019 4 commits
  7. 26 Apr, 2019 15 commits
  8. 11 Feb, 2019 1 commit
    • Andre Przywara's avatar
      arm: Auto-detect guest GIC type · c57e001a
      Andre Przywara authored
      
      
      At the moment kvmtool always tries to instantiate a virtual GICv2
      interrupt controller for the guest, and fails with some scary error
      message if that doesn't work.
      The user has then to manually specify "--irqchip=gicv3", which is not
      really obvious.
      With the advent of more GICv3-only machines, let's try to be more
      clever and implement some auto-detection of the GIC type needed:
      We try gicv3-its, gicv3, gicv2m and gicv2, in that order. The first one
      succeeding wins.
      For GICv2 machines the first two will always fail.
      On GICv3 machines offering GICv2 compatibility we used to prefer a
      virtual GICv2 in the guest, but these days the GICv3 support both in
      guests and in KVM is equally mature and wide-spread, so we should use
      the GICv3 emulation for the guest as well.
      
      This algorithm is in effect is there is no explicit --irqchip parameter
      on the command line. We still allow the GIC type to be set explicitly.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c57e001a
  9. 08 Feb, 2019 8 commits
    • Andre Przywara's avatar
      net/dhcp: avoid misleading strncpy · 0796825e
      Andre Przywara authored
      
      
      The code for copying an empty IP address into the DHCP opt buffer used
      strncpy, however used the source length as the size argument. GCC 8.x
      complains about it.
      
      Since the source string is actually fixed, just revert to the old
      strcpy, which gives us actually the same level of security in this case,
      but makes the compiler happy.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      0796825e
    • Andre Przywara's avatar
      virtio: use strlcpy · 05755b29
      Andre Przywara authored
      
      
      GCC 8.x complains about improper usage of strncpy in virtio/net.c and
      virtio/scsi.c:
      In function 'virtio_scsi_init_one',
          inlined from 'virtio_scsi_init' at virtio/scsi.c:285:7:
      virtio/scsi.c:247:2: error: 'strncpy' specified bound 224 equals destination size [-Werror=stringop-truncation]
        strncpy((char *)&sdev->target.vhost_wwpn, disk->wwpn, sizeof(sdev->target.vhost_wwpn));
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Fix this and the other occurences in virtio/ by using strlcpy instead
      of strncpy.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      05755b29
    • Andre Przywara's avatar
      builtin-run: Replace strncpy calls with strlcpy · 266a0ed4
      Andre Przywara authored
      
      
      There are two uses of strncpy in builtin-run.c, where we don't make
      proper use of strncpy, so that GCC 8.x complains and aborts compilation.
      
      Replace those two calls with strlcpy(), which does the right thing in
      our case.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      266a0ed4
    • Andre Przywara's avatar
      Makefile: support -s switch · 5eb1f27a
      Andre Przywara authored
      
      
      "make -s" suppresses normal output, just shows warnings and errors.
      But since we explicitly override the make output with our fancy concise
      version, we miss out on this feature.
      
      Do as the kernel does and explicitly suppress every normal output when -s
      is given. This helps to spot warnings that scroll out of the terminal
      window too quickly.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5eb1f27a
    • Andre Przywara's avatar
      arm: fdt: add stdout-path to /chosen node · 56e45ea4
      Andre Przywara authored
      
      
      The DT spec describes the stdout-path property in the /chosen node to
      contain the DT path for a default device usable for outputting characters.
      The Linux kernel uses this for earlycon (without further parameters),
      other DT users might rely on this as well.
      
      Add a stdout-path property pointing to the "serial0" alias, then add an
      aliases node at the end of the FDT, containing the actual path. This
      allows the FDT generation code in hw/serial.c to set this string.
      
      Even when we use the virtio console, the serial console is still there
      and works, so we can expose this unconditionally. Putting the virtio
      console path in there will not work anyway.
      Signed-off-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      56e45ea4
    • Anisse Astier's avatar
      kvmtool: 9p: fix overapping snprintf · 04d604b6
      Anisse Astier authored
      
      
      GCC 8.2 gives this warning:
      
      virtio/9p.c: In function ‘virtio_p9_create’:
      virtio/9p.c:335:21: error: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Werror=restrict]
        ret = snprintf(dfid->path, size, "%s/%s", dfid->path, name);
                       ~~~~^~~~~~                 ~~~~~~~~~~
      
      Fix it by allocating a temporary string with dfid->path content instead
      of overwriting it in-place, which is limited in glibc snprintf with the
      __restrict qualifier.
      Reviewed-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarAnisse Astier <aastier@freebox.fr>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      04d604b6
    • Anisse Astier's avatar
      virtio: fix warning on strncpy · 16509081
      Anisse Astier authored
      
      
      GCC 8.2 gives this warning:
      
      virtio/net.c: In function ‘virtio_net__tap_init’:
      virtio/net.c:336:47: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
         strncpy(ifr.ifr_name, ndev->tap_name, sizeof(ndev->tap_name));
                                                     ^
      virtio/net.c:348:47: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
         strncpy(ifr.ifr_name, ndev->tap_name, sizeof(ndev->tap_name));
                                                     ^
      
      Fix it by using sizeof of destination instead, even if they're the same
      size in this case.
      Reviewed-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarAnisse Astier <aastier@freebox.fr>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      16509081
    • Anisse Astier's avatar
      builtin-run: Fix warning when resolving path · 96eda741
      Anisse Astier authored
      
      
      GCC 8.2 gives this warning:
      
      builtin-run.c: In function ‘kvm_run_write_sandbox_cmd.isra.1’:
      builtin-run.c:417:28: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4091 [-Werror=format-truncation=]
         snprintf(dst, len, "/host%s", resolved_path);
                                  ^~   ~~~~~~~~~~~~~
      
      It's because it understands that len is PATH_MAX, the same as
      resolved_path's size. This patch handles the case where the string is
      truncated, and fixes the warning.
      Reviewed-by: Andre Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarAnisse Astier <aastier@freebox.fr>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      96eda741