1. 22 11月, 2019 1 次提交
  2. 15 11月, 2019 1 次提交
  3. 24 10月, 2019 2 次提交
  4. 23 8月, 2019 1 次提交
  5. 07 8月, 2019 1 次提交
  6. 10 4月, 2019 1 次提交
    • M
      domain capabilities: Expose firmware auto selection feature · 5b9819ee
      Michal Privoznik 提交于
      If a management application wants to use firmware auto selection
      feature it can't currently know if the libvirtd it's talking to
      support is or not. Moreover, it doesn't know which values that
      are accepted for the @firmware attribute of <os/> when parsing
      will allow successful start of the domain later, i.e. if the mgmt
      application wants to use 'bios' whether there exists a FW
      descriptor in the system that describes bios.
      
      This commit then adds 'firmware' enum to <os/> element in
      <domainCapabilities/> XML like this:
      
        <enum name='firmware'>
          <value>bios</value>
          <value>efi</value>
        </enum>
      
      We can see both 'bios' and 'efi' listed which means that there
      are descriptors for both found in the system (matched with the
      machine type and architecture reported in the domain capabilities
      earlier and not shown here).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Acked-by: NLaszlo Ersek <lersek@redhat.com>
      5b9819ee
  7. 05 3月, 2019 1 次提交
  8. 15 6月, 2018 1 次提交
    • E
      conf: Fix formatting of <sev> element in domain capabilities XML · 6688393c
      Erik Skultety 提交于
      We only formatted the <sev> element when QEMU supported the feature when
      in fact we should always format the element to make clear that libvirt
      knows about the feature and the fact whether it is or isn't supported
      depends on QEMU version, in other words if QEMU doesn't support the
      feature we're going to format the following into the domain capabilities
      XML:
      
      <sev supported='no'/>
      
      This patch also adjusts the RNG schema accordingly in order to reflect
      the proposed change.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      6688393c
  9. 25 5月, 2018 1 次提交
  10. 04 5月, 2018 2 次提交
  11. 22 7月, 2017 1 次提交
    • D
      qemu: Add AAVMF32 to the list of known UEFIs · 123880d3
      dann frazier 提交于
      Add a path for UEFI VMs for AArch32 VMs, based on the path Debian is using.
      libvirt is the de facto canonical location for defining where distros
      should place these firmware images, so let's define this path here to try
      and minimize distro fragmentation.
      123880d3
  12. 07 3月, 2017 1 次提交
  13. 26 11月, 2016 2 次提交
  14. 22 9月, 2016 4 次提交
    • J
      Show host model in domain capabilities · 14319c81
      Jiri Denemark 提交于
      The domain capabilities XML is capable of showing whether each guest CPU
      mode is supported or not with a possibility to provide additional
      details. This patch enhances host-model capability to advertise the
      exact CPU model which will be used as a host-model:
      
          <cpu>
              ...
              <mode name='host-model' supported='yes'>
                  <model fallback='allow'>Broadwell</model>
                  <vendor>Intel</vendor>
                  <feature policy='disable' name='aes'/>
                  <feature policy='require' name='vmx'/>
              </mode>
              ...
          </cpu>
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      14319c81
    • J
      domcaps: Add CPU usable flag · d4c007e6
      Jiri Denemark 提交于
      In case a hypervisor is able to tell us a list of supported CPU models
      and whether each CPU models can be used on the current host, we can
      propagate this to domain capabilities. This is a better alternative
      to calling virConnectCompareCPU for each supported CPU model.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      d4c007e6
    • J
      qemu: Fill in CPU domain capabilities · 84d38307
      Jiri Denemark 提交于
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      84d38307
    • J
      domcaps: Add support for listing supported CPU models · 167280e7
      Jiri Denemark 提交于
      The patch adds <cpu> element to domain capabilities XML:
      
          <cpu>
              <mode name='host-passthrough' supported='yes'/>
              <mode name='host-model' supported='yes'/>
              <mode name='custom' supported='yes'>
                  <model>Broadwell</model>
                  <model>Broadwell-noTSX</model>
                  ...
              </mode>
          </cpu>
      
      Applications can use it to inspect what CPU configuration modes are
      supported for a specific combination of domain type, emulator binary,
      guest architecture and machine type.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      167280e7
  15. 25 5月, 2016 1 次提交
  16. 16 5月, 2016 1 次提交
  17. 10 5月, 2016 2 次提交
  18. 06 5月, 2016 2 次提交
  19. 20 4月, 2016 1 次提交
  20. 29 1月, 2015 1 次提交
    • M
      qemu: Add AAVMF to the list of known UEFIs · 436dcf0b
      Michal Privoznik 提交于
      Well, even though users can pass the list of UEFI:NVRAM pairs at the
      configure time, we may maintain the list of widely available UEFI
      ourselves too. And as arm64 begin to rises, OVMF was ported there too.
      With a slight name change - it's called AAVMF, with AAVMF_CODE.fd
      being the UEFI firmware and AAVMF_VARS.fd being the NVRAM store file.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      436dcf0b
  21. 17 9月, 2014 2 次提交
  22. 03 7月, 2014 2 次提交
    • M
      qemu: Implement virConnectGetDomainCapabilities · 94e3f23e
      Michal Privoznik 提交于
      So far only information on disks and host devices are exposed in the
      capabilities XML. Well, at least something. Even a new test is
      introduced. The qemu capabilities are stolen from already existing
      qemucapabilities test. There's one tricky point though. Functions that
      checks host's KVM and VFIO capabilities, are impossible to mock
      currently. So in the test, we are setting the capabilities by hand.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      94e3f23e
    • M
      Introduce domain_capabilities · 614581f3
      Michal Privoznik 提交于
      This new module holds and formats capabilities for emulator. If you
      are about to create a new domain, you may want to know what is the
      host or hypervisor capable of. To make sure we don't regress on the
      XML, the formatting is not something left for each driver to
      implement, rather there's general format function.
      
      The domain capabilities is a lockable object (even though the locking
      is not necessary yet) which uses reference counter.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      614581f3