1. 18 1月, 2019 18 次提交
  2. 15 1月, 2019 12 次提交
  3. 14 1月, 2019 10 次提交
    • V
      i386/kvm: add a comment explaining why .feat_names are commented out for Hyper-V feature bits · abd5fc4c
      Vitaly Kuznetsov 提交于
      Hyper-V .feat_names are, unlike hardware features, commented out and it is
      not obvious why we do that. Document the current status quo.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20181221141604.16935-1-vkuznets@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      abd5fc4c
    • E
      x86: host-phys-bits-limit option · 258fe08b
      Eduardo Habkost 提交于
      Some downstream distributions of QEMU set host-phys-bits=on by
      default.  This worked very well for most use cases, because
      phys-bits really didn't have huge consequences. The only
      difference was on the CPUID data seen by guests, and on the
      handling of reserved bits.
      
      This changed in KVM commit 855feb673640 ("KVM: MMU: Add 5 level
      EPT & Shadow page table support").  Now choosing a large
      phys-bits value for a VM has bigger impact: it will make KVM use
      5-level EPT even when it's not really necessary.  This means
      using the host phys-bits value may not be the best choice.
      
      Management software could address this problem by manually
      configuring phys-bits depending on the size of the VM and the
      amount of MMIO address space required for hotplug.  But this is
      not trivial to implement.
      
      However, there's another workaround that would work for most
      cases: keep using the host phys-bits value, but only if it's
      smaller than 48.  This patch makes this possible by introducing a
      new "-cpu" option: "host-phys-bits-limit".  Management software
      or users can make sure they will always use 4-level EPT using:
      "host-phys-bits=on,host-phys-bits-limit=48".
      
      This behavior is still not enabled by default because QEMU
      doesn't enable host-phys-bits=on by default.  But users,
      management software, or downstream distributions may choose to
      change their defaults using the new option.
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20181211192527.13254-1-ehabkost@redhat.com>
      [ehabkost: removed test code while some issues are addressed]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      258fe08b
    • P
      target/i386: Disable MPX support on named CPU models · ecb85fe4
      Paolo Bonzini 提交于
      MPX support is being phased out by Intel; GCC has dropped it, Linux
      is also going to do that.  Even though KVM will have special code
      to support MPX after the kernel proper stops enabling it in XCR0,
      we probably also want to deprecate that in a few years.  As a start,
      do not enable it by default for any named CPU model starting with
      the 4.0 machine types; this include Skylake, Icelake and Cascadelake.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-Id: <20181220121100.21554-1-pbonzini@redhat.com>
      Reviewed-by: N  Wainer dos Santos Moschetta <wainersm@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      ecb85fe4
    • B
      target-i386: Reenable RDTSCP support on Opteron_G[345] CPU models CPU models · 483c6ad4
      Borislav Petkov 提交于
      The missing functionality was added ~3 years ago with the Linux commit
      
        46896c73c1a4 ("KVM: svm: add support for RDTSCP")
      
      so reenable RDTSCP support on those CPU models.
      
      Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
      (the real hardware doesn't have it. K8 got RDTSCP support with the NPT
      models, i.e., models >= 0x40).
      
      Document the host's minimum required kernel version, while at it.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Message-ID: <20181212200803.GG6653@zn.tnic>
      [ehabkost: moved compat properties code to pc.c]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      483c6ad4
    • V
      i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and HV_CPUID_NESTED_FEATURES.EAX as feature words · a2b107db
      Vitaly Kuznetsov 提交于
      It was found that QMP users of QEMU (e.g. libvirt) may need
      HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
      particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
      HV_CPUID_ENLIGHTMENT_INFO.EAX.
      
      HV_CPUID_NESTED_FEATURES.EAX is exposed for two reasons: convenience
      (we don't need to export it from hyperv_handle_properties() and as
      future-proof for Enlightened MSR-Bitmap, PV EPT invalidation and
      direct virtual flush features.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20181126135958.20956-1-vkuznets@redhat.com>
      Reviewed-by: NRoman Kagan <rkagan@virtuozzo.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      a2b107db
    • P
      Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190114' into staging · c9d18c1c
      Peter Maydell 提交于
      Xen queue
      
      * Xen PV backend 'qdevification'.
        Starting with xen_disk.
      * Performance improvements for xen-block.
      * Remove of the Xen PV domain builder.
      * bug fixes.
      
      # gpg: Signature made Mon 14 Jan 2019 13:46:33 GMT
      # gpg:                using RSA key 0CF5572FD7FB55AF
      # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>"
      # gpg:                 aka "Anthony PERARD <anthony.perard@citrix.com>"
      # gpg: WARNING: This key is not certified with sufficiently trusted signatures!
      # gpg:          It is not certain that the signature belongs to the owner.
      # Primary key fingerprint: 5379 2F71 024C 600F 778A  7161 D8D5 7199 DF83 42C8
      #      Subkey fingerprint: F80C 0063 08E2 2CFD 8A92  E798 0CF5 572F D7FB 55AF
      
      * remotes/aperard/tags/pull-xen-20190114: (25 commits)
        xen-block: avoid repeated memory allocation
        xen-block: improve response latency
        xen-block: improve batching behaviour
        xen: Replace few mentions of xend by libxl
        Remove broken Xen PV domain builder
        xen: remove the legacy 'xen_disk' backend
        MAINTAINERS: add myself as a Xen maintainer
        xen: automatically create XenBlockDevice-s
        xen: add a mechanism to automatically create XenDevice-s...
        xen: add implementations of xen-block connect and disconnect functions...
        xen: purge 'blk' and 'ioreq' from function names in dataplane/xen-block.c
        xen: remove 'ioreq' struct/varable/field names from dataplane/xen-block.c
        xen: remove 'XenBlkDev' and 'blkdev' names from dataplane/xen-block
        xen: add header and build dataplane/xen-block.c
        xen: remove unnecessary code from dataplane/xen-block.c
        xen: duplicate xen_disk.c as basis of dataplane/xen-block.c
        xen: add event channel interface for XenDevice-s
        xen: add grant table interface for XenDevice-s
        xen: add xenstore watcher infrastructure
        xen: create xenstore areas for XenDevice-s
        ...
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      c9d18c1c
    • T
      xen-block: avoid repeated memory allocation · c6025bd1
      Tim Smith 提交于
      The xen-block dataplane currently allocates memory to hold the data for
      each request as that request is used, and frees it afterwards. Because
      it requires page-aligned blocks, this interacts poorly with non-page-
      aligned allocations and balloons the heap.
      
      Instead, allocate the maximum possible buffer size required for the
      protocol, which is BLKIF_MAX_SEGMENTS_PER_REQUEST (currently 11) pages
      when the request structure is created, and keep that buffer until it is
      destroyed. Since the requests are re-used via a free list, this should
      actually improve memory usage.
      Signed-off-by: NTim Smith <tim.smith@citrix.com>
      
      Re-based and commit comment adjusted.
      Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
      Acked-by: NAnthony PERARD <anthony.perard@citrix.com>
      Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
      c6025bd1
    • T
      xen-block: improve response latency · bfd0d636
      Tim Smith 提交于
      If the I/O ring is full, the guest cannot send any more requests
      until some responses are sent. Only sending all available responses
      just before checking for new work does not leave much time for the
      guest to supply new work, so this will cause stalls if the ring gets
      full. Also, not completing reads as soon as possible adds latency
      to the guest.
      
      To alleviate that, complete IO requests as soon as they come back.
      xen_block_send_response() already returns a value indicating whether
      a notify should be sent, which is all the batching we need.
      Signed-off-by: NTim Smith <tim.smith@citrix.com>
      
      Re-based and commit comment adjusted.
      Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
      Acked-by: NAnthony PERARD <anthony.perard@citrix.com>
      Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
      bfd0d636
    • T
      xen-block: improve batching behaviour · 6de45f91
      Tim Smith 提交于
      When I/O consists of many small requests, performance is improved by
      batching them together in a single io_submit() call. When there are
      relatively few requests, the extra overhead is not worth it. This
      introduces a check to start batching I/O requests via blk_io_plug()/
      blk_io_unplug() in an amount proportional to the number which were
      already in flight at the time we started reading the ring.
      Signed-off-by: NTim Smith <tim.smith@citrix.com>
      
      Re-based and commit comment adjusted.
      Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
      Acked-by: NAnthony PERARD <anthony.perard@citrix.com>
      Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
      6de45f91
    • A
      xen: Replace few mentions of xend by libxl · 1077bcac
      Anthony PERARD 提交于
      xend have been replaced by libxenlight (libxl) for many Xen releases
      now.
      Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
      Acked-by: NStefano Stabellini <sstabellini@kernel.org>
      1077bcac