1. 17 6月, 2019 1 次提交
  2. 03 6月, 2019 1 次提交
  3. 23 5月, 2019 1 次提交
  4. 29 4月, 2019 1 次提交
  5. 16 4月, 2019 3 次提交
  6. 14 3月, 2019 1 次提交
    • J
      conf: Add a new 'xenbus' controller type · 09eb1ae0
      Jim Fehlig 提交于
      xenbus is virtual controller (akin to virtio controllers) for Xen
      paravirtual devices. Although all Xen VMs have a xenbus, it has
      never been modeled in libvirt, or in Xen native VM config format
      for that matter.
      
      Recently there have been requests to support Xen's max_grant_frames
      setting in libvirt. max_grant_frames is best modeled as an attribute
      of xenbus. It describes the maximum IO buffer space (or DMA space)
      available in xenbus for use by connected paravirtual devices. This
      patch introduces a new xenbus controller type that includes a
      maxGrantFrames attribute.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      09eb1ae0
  7. 12 3月, 2019 1 次提交
    • M
      conf: Introduce firmware attribute to <os/> · d947fa8a
      Michal Privoznik 提交于
      The idea is that using this attribute users enable libvirt to
      automagically select firmware image for their domain. For
      instance:
      
        <os firmware='efi'>
          <type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
          <loader secure='no'/>
        </os>
      
        <os firmware='bios'>
          <type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
        </os>
      
      (The automagic of selecting firmware image will be described in
      later commits.)
      
      Accepted values are 'bios' and 'efi' to let libvirt select
      corresponding type of firmware.
      
      I know it is a good sign to introduce xml2xml test case when
      changing XML config parser but that will have to come later.
      Firmware auto selection is not enabled for any driver just yet so
      any xml2xml test would fail right away.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      d947fa8a
  8. 11 3月, 2019 1 次提交
  9. 06 3月, 2019 1 次提交
  10. 05 3月, 2019 10 次提交
  11. 24 2月, 2019 1 次提交
  12. 19 2月, 2019 1 次提交
  13. 08 2月, 2019 1 次提交
  14. 02 1月, 2019 3 次提交
  15. 18 12月, 2018 2 次提交
  16. 03 12月, 2018 1 次提交
  17. 28 11月, 2018 1 次提交
  18. 19 11月, 2018 1 次提交
  19. 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
  20. 15 11月, 2018 6 次提交
  21. 30 10月, 2018 1 次提交