1. 06 1月, 2017 1 次提交
  2. 28 11月, 2016 1 次提交
  3. 26 11月, 2016 6 次提交
  4. 22 9月, 2016 5 次提交
    • 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
      qemu: Store host-model CPU in qemu capabilities · 68c70118
      Jiri Denemark 提交于
      Host capabilities provide libvirt's view of the host CPU, but for a
      useful support for host-model CPUs we really need a hypervisor's view of
      the CPU. And since the view can be differ with emulator, qemu
      capabilities is the best place to store the host CPU model.
      
      This patch just copies the CPU model from host capabilities, but this
      will change in the future.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      68c70118
    • 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
  5. 01 7月, 2016 2 次提交
  6. 25 6月, 2016 1 次提交
  7. 18 6月, 2016 1 次提交
  8. 14 6月, 2016 2 次提交
  9. 08 6月, 2016 2 次提交
  10. 25 5月, 2016 1 次提交
  11. 16 5月, 2016 3 次提交
  12. 10 5月, 2016 2 次提交
  13. 06 5月, 2016 5 次提交
  14. 20 4月, 2016 1 次提交
    • A
      conf: Get rid of virDomainCapsDevice · 29980231
      Andrea Bolognani 提交于
      The struct contains a single boolean field, 'supported':
      the meaning of this field is too generic to be limited to
      devices only, and in fact it's already being used for
      other things like loaders and OSs.
      
      Instead of trying to come up with a more generic name just
      get rid of the struct altogether.
      29980231
  15. 27 4月, 2015 1 次提交
  16. 24 4月, 2015 1 次提交
  17. 29 1月, 2015 2 次提交
    • 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
    • M
      qemu: Allow UEFI paths to be specified at compile time · bc03a231
      Michal Privoznik 提交于
      Up until now there are just two ways how to specify UEFI paths to
      libvirt. The first one is editing qemu.conf, the other is editing
      qemu_conf.c and recompile which is not that fancy. So, new
      configure option is introduced: --with-loader-nvram which takes a
      list of pairs of UEFI firmware and NVRAM store. This way, the
      compiled in defaults can be passed during compile time without
      need to change the code itself.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      bc03a231
  18. 27 1月, 2015 1 次提交
  19. 18 9月, 2014 1 次提交
    • R
      Fix build in qemu_capabilities · 3b3947ea
      Roman Bogorodskiy 提交于
      Commit f05b6a91 added virQEMUDriverConfigPtr argument to the
      virQEMUCapsFillDomainCaps function and it uses forward declaration
      of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang
      build to fail:
      
      gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src'
        CC       qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo
      In file included from qemu/qemu_capabilities.c:43:
      In file included from qemu/qemu_hostdev.h:27:
      qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig'
      is a C11 feature [-Werror,-Wtypedef-redefinition]
      typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                          ^
      qemu/qemu_capabilities.h:328:37: note: previous definition is here
      typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                          ^
      
      Fix that by passing loader and nloader config attributes directly
      instead of passing complete config.
      3b3947ea
  20. 17 9月, 2014 1 次提交