1. 13 12月, 2018 35 次提交
  2. 12 12月, 2018 5 次提交
    • P
      hw/s390x/virtio-ccw.c: Don't take address of fields in packed structs · c9aacaad
      Peter Maydell 提交于
      Taking the address of a field in a packed struct is a bad idea, because
      it might not be actually aligned enough for that pointer type (and
      thus cause a crash on dereference on some host architectures). Newer
      versions of clang warn about this. Avoid the bug by not using the
      "modify in place" byte swapping functions.
      
      Patch produced with scripts/coccinelle/inplace-byteswaps.cocci
      (with a couple of long lines manually wrapped).
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-Id: <20181210120436.30522-1-peter.maydell@linaro.org>
      Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
      Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      c9aacaad
    • C
      vfio-ap: flag as compatible with balloon · 1883e8fc
      Cornelia Huck 提交于
      vfio-ap devices do not pin any pages in the host. Therefore, they
      are compatible with memory ballooning.
      
      Flag them as compatible, so both vfio-ap and a balloon can be
      used simultaneously.
      
      Cc: qemu-stable@nongnu.org
      Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Tested-by: NTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      1883e8fc
    • D
      s390x/tod: Properly stop the KVM TOD while the guest is not running · 9bc9d3d1
      David Hildenbrand 提交于
      Just like on other architectures, we should stop the clock while the guest
      is not running. This is already properly done for TCG. Right now, doing an
      offline migration (stop, migrate, cont) can easily trigger stalls in the
      guest.
      
      Even doing a
          (hmp) stop
          ... wait 2 minutes ...
          (hmp) cont
      will already trigger stalls.
      
      So whenever the guest stops, backup the KVM TOD. When continuing to run
      the guest, restore the KVM TOD.
      
      One special case is starting a simple VM: Reading the TOD from KVM to
      stop it right away until the guest is actually started means that the
      time of any simple VM will already differ to the host time. We can
      simply leave the TOD running and the guest won't be able to recognize
      it.
      
      For migration, we actually want to keep the TOD stopped until really
      starting the guest. To be able to catch most errors, we should however
      try to set the TOD in addition to simply storing it. So we can still
      catch basic migration problems.
      
      If anything goes wrong while backing up/restoring the TOD, we have to
      ignore it (but print a warning). This is then basically a fallback to
      old behavior (TOD remains running).
      
      I tested this very basically with an initrd:
          1. Start a simple VM. Observed that the TOD is kept running. Old
             behavior.
          2. Ordinary live migration. Observed that the TOD is temporarily
             stopped on the destination when setting the new value and
             correctly started when finally starting the guest.
          3. Offline live migration. (stop, migrate, cont). Observed that the
             TOD will be stopped on the source with the "stop" command. On the
             destination, the TOD is temporarily stopped when setting the new
             value and correctly started when finally starting the guest via
             "cont".
          4. Simple stop/cont correctly stops/starts the TOD. (multiple stops
             or conts in a row have no effect, so works as expected)
      
      In the future, we might want to send the guest a special kind of time sync
      interrupt under some conditions, so it can synchronize its tod to the
      host tod. This is interesting for migration scenarios but also when we
      get time sync interrupts ourselves. This however will most probably have
      to be handled in KVM (e.g. when the tods differ too much) and is not
      desired e.g. when debugging the guest (single stepping should not
      result in permanent time syncs). I consider something like that an add-on
      on top of this basic "don't break the guest" handling.
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Message-Id: <20181130094957.4121-1-david@redhat.com>
      Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NThomas Huth <thuth@redhat.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      9bc9d3d1
    • C
      s390/MAINTAINERS: Add Halil as kvm and machine maintainer · 7c8e2647
      Christian Borntraeger 提交于
      Halil does more work in this area than I do right now. Lets add Halil.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Message-Id: <20181204133802.100998-1-borntraeger@de.ibm.com>
      Acked-by: NHalil Pasic <pasic@linux.ibm.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      7c8e2647
    • C
      s390x: introduce 4.0 compat machine · 8c7b0c73
      Cornelia Huck 提交于
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      8c7b0c73