1. 27 1月, 2019 1 次提交
    • R
      bhyve: implement support for commandline args · 0c8df110
      Roman Bogorodskiy 提交于
      Implement support for passing custom command line arguments
      to bhyve using the 'bhyve:commandline' element:
      
        <bhyve:commandline>
          <bhyve:arg value='-newarg'/>
        </bhyve:commandline>
      
       * Define virDomainXMLNamespace for the bhyve driver, which
         at this point supports only the 'commandline' element
         described above,
       * Update command generation code to inject these command line
         arguments between driver-generated arguments and the vmname
         positional argument.
      Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      0c8df110
  2. 04 1月, 2019 1 次提交
  3. 02 1月, 2019 3 次提交
  4. 18 12月, 2018 1 次提交
  5. 13 12月, 2018 1 次提交
  6. 03 12月, 2018 2 次提交
  7. 28 11月, 2018 1 次提交
  8. 27 11月, 2018 1 次提交
  9. 16 11月, 2018 1 次提交
    • M
      qemu: add memfd source type · 24b74d18
      Marc-André Lureau 提交于
      Add a new memoryBacking source type "memfd", supported by QEMU (when
      the capability is available).
      
      A memfd is a specialized anonymous memory kind. As such, an anonymous
      source type could be automatically using a memfd. However, there are
      some complications when migrating from different memory backends in
      qemu (mainly due to the internal object naming at this point, but
      there could be more). For now, it is simpler and safer to simply
      introduce a new source type "memfd". Eventually, the "anonymous" type
      could learn to use memfd transparently in a separate change.
      
      The main benefits are that it doesn't need to create filesystem files,
      and it also enforces sealing, providing a bit more safety.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      24b74d18
  10. 15 11月, 2018 5 次提交
  11. 30 10月, 2018 1 次提交
  12. 21 9月, 2018 1 次提交
    • W
      conf: Introduce RDT monitor host capability · 6af84174
      Wang Huaqiang 提交于
      This patch is introducing cache monitor(CMT) to cache and
      memory bandwidth monitor(MBM) for monitoring CPU memory
      bandwidth.
      
      The host capability of the two monitors is also introduced
      in this patch.
      
      For CMT, the host capability is shown like:
        <host>
        ...
          <cache>
            <bank id='0' level='3' type='both' size='15' unit='MiB' cpus='0-5'>
              <control granularity='768' min='1536' unit='KiB' type='both' maxAllocs='4'/>
            </bank>
            <monitor level='3' 'reuseThreshold'='270336' maxMonitors='176'>
              <feature name='llc_occupancy'/>
            </monitor>
          </cache>
          ...
        </host>
      
      For MBM, the capability is shown like this:
        <host>
          ...
          <memory_bandwidth>
            <node id='1' cpus='6-11'>
              <control granularity='10' min ='10' maxAllocs='4'/>
            </node>
            <monitor maxMonitors='176'>
              <feature name='mbm_total_bytes'/>
              <feature name='mbm_local_bytes'/>
            </monitor>
          </memory_bandwidth>
          ...
        </host>
      Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      6af84174
  13. 11 9月, 2018 1 次提交
  14. 08 9月, 2018 1 次提交
  15. 28 8月, 2018 1 次提交
    • A
      qemu: Introduce 16550A serial console model · 9610eaa4
      Andrea Bolognani 提交于
      None of the existing models is suitable for use with
      RISC-V virt guests, and we don't want information about
      the serial console to be missing from the XML.
      
      The name is based on comments in qemu/hw/riscv/virt.c:
      
        RISC-V machine with 16550a UART and VirtIO MMIO
      
      and in qemu/hw/char/serial.c:
      
        QEMU 16550A UART emulation
      
      along with the output of dmesg in the guest:
      
        Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
        10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
          base_baud= 230400) is a 16550A
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      9610eaa4
  16. 24 8月, 2018 1 次提交
  17. 21 8月, 2018 1 次提交
  18. 17 8月, 2018 3 次提交
  19. 14 8月, 2018 2 次提交
    • B
      conf: Add memory bandwidth allocation capability of host · 7995fecc
      Bing Niu 提交于
      Add new XML section to report host's memory bandwidth allocation
      capability. The format as below example:
      
       <host>
       .....
         <memory_bandwidth>
           <node id='0' cpus='0-19'>
             <control granularity='10' min ='10' maxAllocs='8'/>
           </node>
         </memory_bandwidth>
      </host>
      
      granularity   ---- granularity of memory bandwidth, unit percentage.
      min           ---- minimum memory bandwidth allowed, unit percentage.
      maxAllocs     ---- maximum memory bandwidth allocation group supported.
      Signed-off-by: NBing Niu <bing.niu@intel.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      7995fecc
    • B
      conf: Add support for memorytune XML processing for resctrl MBA · 6956b7ee
      Bing Niu 提交于
      Introduce a new section memorytune to support memory bandwidth allocation.
      This is consistent with existing cachetune. As the example:
      below:
        <cputune>
          ......
          <memorytune vcpus='0'>
            <node id='0' bandwidth='30'/>
          </memorytune>
        </cputune>
      
      vpus      --- vpus subjected to this memory bandwidth.
      id        --- on which node memory bandwidth to be set.
      bandwidth --- the memory bandwidth percent to set.
      Signed-off-by: NBing Niu <bing.niu@intel.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      6956b7ee
  20. 08 8月, 2018 2 次提交
  21. 06 8月, 2018 1 次提交
  22. 19 7月, 2018 3 次提交
    • E
      conf: Introduce new video type 'none' · d48813e8
      Erik Skultety 提交于
      Historically, we've always enabled an emulated video device every time we
      see that graphics should be supported with a guest. With the appearance
      of mediated devices which can support QEMU's vfio-display capability,
      users might want to use such a device as the only video device.
      Therefore introduce a new, effectively a 'disable', type for video
      device.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d48813e8
    • E
      conf: Introduce new <hostdev> attribute 'display' · d54e45b6
      Erik Skultety 提交于
      QEMU 2.12 introduced a new type of display for mediated devices using
      vfio-pci backend which allows a mediated device to be used as a VGA
      compatible device as an alternative to an emulated video device. QEMU
      exposes this feature via a vfio device property 'display' with supported
      values 'on/off/auto' (libvirt will default to 'off').
      
      This patch adds the necessary bits to domain config handling in order to
      expose this feature. Since there's no convenient way for libvirt to come
      up with usable defaults for the display setting, simply because libvirt
      is not able to figure out which of the display implementations - dma-buf
      which requires OpenGL support vs vfio regions which doesn't need OpenGL
      (works with OpenGL enabled too) - the underlying mdev uses.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d54e45b6
    • E
      qemu: Introduce a new graphics display type 'headless' · d8266ebe
      Erik Skultety 提交于
      Since 2.10 QEMU supports a new display type egl-headless which uses the
      drm nodes for OpenGL rendering copying back the rendered bits back to
      QEMU into a dma-buf which can be accessed by standard "display" apps
      like VNC or SPICE. Although this display type can be used on its own,
      for any practical use case it makes sense to pair it with either VNC or
      SPICE display. The clear benefit of this display is that VNC gains
      OpenGL support, which it natively doesn't have, and SPICE gains remote
      OpenGL support (native OpenGL support only works locally through a UNIX
      socket, i.e. listen type=socket/none).
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d8266ebe
  23. 13 7月, 2018 1 次提交
  24. 03 7月, 2018 1 次提交
  25. 26 6月, 2018 3 次提交