1. 29 Nov, 2017 5 commits
  2. 28 Nov, 2017 1 commit
  3. 27 Nov, 2017 4 commits
  4. 24 Nov, 2017 4 commits
  5. 23 Nov, 2017 5 commits
  6. 22 Nov, 2017 4 commits
    • Daniel Henrique Barboza's avatar
      migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END · acab30b8
      Daniel Henrique Barboza authored
      
      When migrating a VM with 'migrate_set_capability postcopy-ram on'
      a postcopy_state is set during the process, ending up with the
      state POSTCOPY_INCOMING_END when the migration is over. This
      postcopy_state is taken into account inside ram_load to check
      how it will load the memory pages. This same ram_load is called when
      in a loadvm command.
      
      Inside ram_load, the logic to see if we're at postcopy_running state
      is:
      
      postcopy_running = postcopy_state_get() >= POSTCOPY_INCOMING_LISTENING
      
      postcopy_state_get() returns this enum type:
      
      typedef enum {
          POSTCOPY_INCOMING_NONE = 0,
          POSTCOPY_INCOMING_ADVISE,
          POSTCOPY_INCOMING_DISCARD,
          POSTCOPY_INCOMING_LISTENING,
          POSTCOPY_INCOMING_RUNNING,
          POSTCOPY_INCOMING_END
      } PostcopyState;
      
      In the case where ram_load is executed and postcopy_state is
      POSTCOPY_INCOMING_END, postcopy_running will be set to 'true' and
      ram_load will behave like a postcopy is in progress. This scenario isn't
      achievable in a migration but it is reproducible when executing
      savevm/loadvm after migrating with 'postcopy-ram on', causing loadvm
      to fail with Error -22:
      
      Source:
      
      (qemu) migrate_set_capability postcopy-ram on
      (qemu) migrate tcp:127.0.0.1:4444
      
      Dest:
      
      (qemu) migrate_set_capability postcopy-ram on
      (qemu)
      ubuntu1704-intel login:
      Ubuntu 17.04 ubuntu1704-intel ttyS0
      
      ubuntu1704-intel login: (qemu)
      (qemu) savevm test1
      (qemu) loadvm test1
      Unknown combination of migration flags: 0x4 (postcopy mode)
      error while loading state for instance 0x0 of device 'ram'
      Error -22 while loading VM state
      (qemu)
      
      This patch fixes this problem by changing the existing logic for
      postcopy_advised and postcopy_running in ram_load, making them
      'false' if we're at POSTCOPY_INCOMING_END state.
      
      Signed-off-by: default avatarDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
      CC: Juan Quintela <quintela@redhat.com>
      CC: Dr. David Alan Gilbert <dgilbert@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
      Reported-by: default avatarBalamuruhan S <bala24@linux.vnet.ibm.com>
      Signed-off-by: default avatarJuan Quintela <quintela@redhat.com>
      acab30b8
    • Laurent Vivier's avatar
      ppc: fix VTB migration · 6dd836f5
      Laurent Vivier authored
      Migration of a system under stress (for example, with
      "stress-ng --numa 2") triggers on the destination
      some kernel watchdog messages like:
      
      NMI watchdog: BUG: soft lockup - CPU#0 stuck for 3489660870s!
      NMI watchdog: BUG: soft lockup - CPU#1 stuck for 3489660884s!
      
      This problem appears with the changes introduced by
          42043e4f spapr: clock should count only if vm is running
      
      I think this commit only triggers the problem.
      
      Kernel computes the soft lockup duration using the
      Virtual Timebase register (VTB), not using the Timebase
      Register (TBR, the one 42043e4f
      
       stops).
      
      It appears VTB is not migrated, so this patch adds it in
      the list of the SPRs to migrate, and fixes the problem.
      
      For the migration, I've tested a migration from qemu-2.8.0 and
      pseries-2.8.0 to a patched master (qemu-2.11.0-rc1). The received
      VTB is 0 (as is it not initialized by qemu-2.8.0), but the value
      seems to be ignored by KVM and a non zero VTB is used by the kernel.
      I have no explanation for that, but as the original problem appears
      only with SMP system under stress I suspect some problems in KVM
      (I think because VTB is shared by all threads of a core).
      
      Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      6dd836f5
    • David Gibson's avatar
      spapr: Implement bug in spapr-vty device to be compatible with PowerVM · 6c3bc244
      David Gibson authored
      
      The spapr-vty device implements the PAPR defined virtual console,
      which is also implemented by IBM's proprietary PowerVM hypervisor.
      
      PowerVM's implementation has a bug where it inserts an extra \0 after
      every \r going to the guest.  Because of that Linux's guest side
      driver has a workaround which strips \0 characters that appear
      immediately after a \r.
      
      That means that when running under qemu, sending a binary stream from
      host to guest via spapr-vty which happens to include a \r\0 sequence
      will get corrupted by that workaround.
      
      To deal with that, this patch duplicates PowerVM's bug, inserting an
      extra \0 after each \r.  Ugly, but the best option available.
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      6c3bc244
    • Thomas Huth's avatar
      hw/ppc/spapr: Fix virtio-scsi bootindex handling for LUNs >= 256 · bac658d1
      Thomas Huth authored
      LUNs >= 256 have to be encoded with the so-called "flat space
      addressing method" for virtio-scsi, where an additional bit has to
      be set. SLOF already took care of this with the following commit:
      
       https://git.qemu.org/?p=SLOF.git;a=commitdiff;h=f72a37713fea47da
       (see https://bugzilla.redhat.com/show_bug.cgi?id=1431584
      
       for details)
      
      But QEMU does not use this encoding yet for device tree paths
      that have to be handed over to SLOF to deal with the "bootindex"
      property, so SLOF currently fails to boot from virtio-scsi devices
      with LUNs >= 256 in the right boot order. Fix it by using the bit
      to indicate the "flat space addressing method" for LUNs >= 256.
      
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      bac658d1
  7. 21 Nov, 2017 17 commits