1. 06 9月, 2016 4 次提交
    • M
      s390x/cpumodel: generate CPU feature lists for CPU models · dced7eec
      Michael Mueller 提交于
      This patch introduces the helper "gen-features" which allows to generate
      feature list definitions at compile time. Its flexibility is better and the
      error-proneness is lower when compared to static programming time added
      statements.
      
      The helper includes "target-s390x/cpu_features.h" to be able to use named
      facility bits instead of numbers. The generated defines will be used for
      the definition of CPU models.
      
      We generate feature lists for each HW generation and GA for EC models. BC
      models are always based on a EC version and have no separate definitions.
      
      Base features: Features we expect to be always available in sane setups.
      Migration safe - will never change. Can be seen as "minimum features
      required for a CPU model".
      
      Default features: Features we expect to be stable and around in latest
      setups (e.g. having KVM support) - not migration safe.
      
      Max features: All supported features that are theoretically allowed for a
      CPU model. Exceeding these features could otherwise produce problems with
      IBC (instruction blocking controls) in KVM.
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NMichael Mueller <mimu@linux.vnet.ibm.com>
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      [generate base, default and models. renaming and cleanup]
      Message-Id: <20160905085244.99980-6-dahi@linux.vnet.ibm.com>
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      dced7eec
    • M
      s390x/cpumodel: introduce CPU features · 78241744
      Michael Mueller 提交于
      The patch introduces s390x CPU features (most of them refered to as
      facilities) along with their discription and some functions that will be
      helpful when working with the features later on.
      
      Please note that we don't introduce all known CPU features, only the
      ones currently supported by KVM + QEMU. We don't want to enable later
      on blindly any facilities, for which we don't know yet if we need QEMU
      support to properly support them (e.g. migrate additional state when
      active). We can update QEMU later on.
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NMichael Mueller <mimu@linux.vnet.ibm.com>
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      [reworked to include non-stfle features, added definitions]
      Message-Id: <20160905085244.99980-5-dahi@linux.vnet.ibm.com>
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      78241744
    • D
      s390x/cpumodel: expose CPU class properties · 6efadc90
      David Hildenbrand 提交于
      Let's expose the description and migration safety and whether a definition
      is static, as class properties, this can be helpful in the future.
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Message-Id: <20160905085244.99980-4-dahi@linux.vnet.ibm.com>
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      6efadc90
    • D
      s390x/cpumodel: "host" and "qemu" as CPU subclasses · 41868f84
      David Hildenbrand 提交于
      This patch introduces two CPU models, "host" and "qemu".
      "qemu" is used as default when running under TCG. "host" is used
      as default when running under KVM. "host" cannot be used without KVM.
      "host" is not migration-safe. They both inherit from the base s390x CPU,
      which is turned into an abstract class.
      
      This patch also changes CPU creation to take care of the passed CPU string
      and reuses common code parse_features() function for that purpose. Unknown
      CPU definitions are now reported. The "-cpu ?" and "query-cpu-definition"
      commands are changed to list all CPU subclasses automatically, including
      migration-safety and whether static.
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Message-Id: <20160905085244.99980-3-dahi@linux.vnet.ibm.com>
      [CH: fix up self-assignments in s390_cpu_list, as spotted by clang]
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      41868f84
  2. 05 9月, 2016 11 次提交
  3. 02 9月, 2016 1 次提交
  4. 31 8月, 2016 5 次提交
  5. 30 8月, 2016 4 次提交
  6. 25 8月, 2016 1 次提交
    • P
      Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging · e00da552
      Peter Maydell 提交于
      virtio: fixes
      
      some bugfixes for virtio
      balloon is still broken wrt migration
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      
      # gpg: Signature made Tue 23 Aug 2016 17:33:11 BST
      # gpg:                using RSA key 0x281F0DB8D28D5469
      # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
      # gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"
      # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
      #      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469
      
      * remotes/mst/tags/for_upstream:
        virtio: decrement vq->inuse in virtqueue_discard()
        virtio: recalculate vq->inuse after migration
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      e00da552
  7. 24 8月, 2016 3 次提交
  8. 22 8月, 2016 4 次提交
  9. 19 8月, 2016 4 次提交
  10. 18 8月, 2016 3 次提交
    • P
      Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging · 02b1ad88
      Peter Maydell 提交于
      # gpg: Signature made Thu 18 Aug 2016 14:39:31 BST
      # gpg:                using RSA key 0x9CA4ABB381AB73C8
      # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
      # gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
      # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8
      
      * remotes/stefanha/tags/block-pull-request:
        block: fix possible reorder of flush operations
        block: fix deadlock in bdrv_co_flush
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      02b1ad88
    • D
      block: fix possible reorder of flush operations · 156af3ac
      Denis V. Lunev 提交于
      This patch reduce CPU usage of flush operations a bit. When we have one
      flush completed we should kick only next operation. We should not start
      all pending operations in the hope that they will go back to wait on
      wait_queue.
      
      Also there is a technical possibility that requests will get reordered
      with the previous approach. After wakeup all requests are removed from
      the wait queue. They become active and they are processed one-by-one
      adding to the wait queue in the same order. Though new flush can arrive
      while all requests are not put into the queue.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Tested-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com>
      Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com>
      Message-id: 1471457214-3994-3-git-send-email-den@openvz.org
      CC: Stefan Hajnoczi <stefanha@redhat.com>
      CC: Fam Zheng <famz@redhat.com>
      CC: Kevin Wolf <kwolf@redhat.com>
      CC: Max Reitz <mreitz@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      156af3ac
    • E
      block: fix deadlock in bdrv_co_flush · ce83ee57
      Evgeny Yakovlev 提交于
      The following commit
          commit 3ff2f67a
          Author: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
          Date:   Mon Jul 18 22:39:52 2016 +0300
          block: ignore flush requests when storage is clean
      has introduced a regression.
      
      There is a problem that it is still possible for 2 requests to execute
      in non sequential fashion and sometimes this results in a deadlock
      when bdrv_drain_one/all are called for BDS with such stalled requests.
      
      1. Current flushed_gen and flush_started_gen is 1.
      2. Request 1 enters bdrv_co_flush to with write_gen 1 (i.e. the same
         as flushed_gen). It gets past flushed_gen != flush_started_gen and
         sets flush_started_gen to 1 (again, the same it was before).
      3. Request 1 yields somewhere before exiting bdrv_co_flush
      4. Request 2 enters bdrv_co_flush with write_gen 2. It gets past
         flushed_gen != flush_started_gen and sets flush_started_gen to 2.
      5. Request 2 runs to completion and sets flushed_gen to 2
      6. Request 1 is resumed, runs to completion and sets flushed_gen to 1.
         However flush_started_gen is now 2.
      
      From here on out flushed_gen is always != to flush_started_gen and all
      further requests will wait on flush_queue. This change replaces
      flush_started_gen with an explicitly tracked active flush request.
      Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com>
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Message-id: 1471457214-3994-2-git-send-email-den@openvz.org
      CC: Stefan Hajnoczi <stefanha@redhat.com>
      CC: Fam Zheng <famz@redhat.com>
      CC: Kevin Wolf <kwolf@redhat.com>
      CC: Max Reitz <mreitz@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      ce83ee57