1. 05 3月, 2019 1 次提交
    • C
      conf: Add <disk model='virtio-{non-}transitional'/> · 25d05051
      Cole Robinson 提交于
      <disk> devices lack the model= attribute which is used by
      most other device types. bus= mostly acts as one, but it
      serves other purposes too like determing what target=
      prefix to use, and for matching against controller type=
      values.
      
      Extending bus= to handle additional virtio transitional
      devices will complicate apps lives, and it isn't a clean
      mapping anyways. So let's bite the bullet and add a new
      <disk model=X/> attribute, and wire up common handling
      for virtio and virtio-{non-}transitional
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NCole Robinson <crobinso@redhat.com>
      25d05051
  2. 24 2月, 2019 1 次提交
  3. 06 2月, 2019 1 次提交
  4. 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
  5. 04 1月, 2019 1 次提交
  6. 02 1月, 2019 3 次提交
  7. 18 12月, 2018 1 次提交
  8. 03 12月, 2018 1 次提交
  9. 28 11月, 2018 1 次提交
  10. 27 11月, 2018 1 次提交
  11. 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
  12. 15 11月, 2018 5 次提交
  13. 30 10月, 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. 21 8月, 2018 1 次提交
  17. 17 8月, 2018 3 次提交
  18. 14 8月, 2018 1 次提交
  19. 08 8月, 2018 1 次提交
  20. 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
  21. 13 7月, 2018 1 次提交
  22. 03 7月, 2018 1 次提交
  23. 26 6月, 2018 3 次提交
  24. 13 6月, 2018 1 次提交
  25. 12 6月, 2018 1 次提交
    • B
      conf: Introduce launch-security element in domain · e5791a03
      Brijesh Singh 提交于
      The launch-security element can be used to define the security
      model to use when launching a domain. Currently we support 'sev'.
      
      When 'sev' is used, the VM will be launched with AMD SEV feature enabled.
      SEV feature supports running encrypted VM under the control of KVM.
      Encrypted VMs have their pages (code and data) secured such that only the
      guest itself has access to the unencrypted version. Each encrypted VM is
      associated with a unique encryption key; if its data is accessed to a
      different entity using a different key the encrypted guests data will be
      incorrectly decrypted, leading to unintelligible data.
      Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      e5791a03
  26. 08 6月, 2018 1 次提交
    • M
      conf, schema, docs: Add support for TSEG size setting · 1bd5a08d
      Martin Kletzander 提交于
      TSEG (Top of Memory Segment) is one of many regions that SMM (System Management
      Mode) can occupy.  This one, however is special, because a) most of the SMM code
      lives in TSEG nowadays and b) QEMU just (well, some time ago) added support for
      so called 'extended' TSEG.  The difference to the TSEG implemented in real q35's
      MCH (Memory Controller Hub) is that it can offer one extra size to the guest OS
      apart from the standard TSEG's 1, 2, and 8 MiB and that size can be selected in
      1 MiB increments.  Maximum may vary based on QEMU and is way too big, so we
      don't need to check for the maximum here.  Similarly to the memory size we'll
      leave it to the hypervisor to try satisfying that and giving us an error message
      in case it is not possible.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      Acked-by: NLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      1bd5a08d
  27. 06 6月, 2018 2 次提交