1. 01 12月, 2010 1 次提交
  2. 17 11月, 2010 1 次提交
    • E
      maint: use gnulib configmake rather than open-coding things · 0d5f54bb
      Eric Blake 提交于
      * bootstrap.conf (gnulib_modules): Add configmake.
      * daemon/Makefile.am (libvirtd_CFLAGS): Drop defines provided by
      gnulib.
      * src/Makefile.am (INCLUDES): Likewise.
      * tests/Makefile.am (INCLUDES): Likewise.
      * tools/Makefile.am (virsh_CFLAGS): Likewise.
      * daemon/libvirtd.c (qemudInitPaths, usage, main): Update
      clients.
      * src/cpu/cpu_map.c (CPUMAPFILE): Likewise.
      * src/driver.c (DEFAULT_DRIVER_DIR): Likewise.
      * src/internal.h (_): Likewise.
      * src/libvirt.c (virInitialize): Likewise.
      * src/lxc/lxc_conf.h (LXC_CONFIG_DIR, LXC_STATE_DIR, LXC_LOG_DIR):
      Likewise.
      * src/lxc/lxc_conf.c (lxcCapsInit, lxcLoadDriverConfig):
      Likewise.
      * src/network/bridge_driver.c (NETWORK_PID_DIR)
      (NETWORK_STATE_DIR, DNSMASQ_STATE_DIR, networkStartup): Likewise.
      * src/nwfilter/nwfilter_driver.c (nwfilterDriverStartup):
      Likewise.
      * src/qemu/qemu_conf.c (qemudLoadDriverConfig): Likewise.
      * src/qemu/qemu_driver.c (qemudStartup): Likewise.
      * src/remote/remote_driver.h (LIBVIRTD_PRIV_UNIX_SOCKET)
      (LIBVIRTD_PRIV_UNIX_SOCKET_RO, LIBVIRTD_CONFIGURATION_FILE)
      (LIBVIRT_PKI_DIR): Likewise.
      * src/secret/secret_driver.c (secretDriverStartup): Likewise.
      * src/security/security_apparmor.c (VIRT_AA_HELPER): Likewise.
      * src/security/virt-aa-helper.c (main): Likewise.
      * src/storage/storage_backend_disk.c (PARTHELPER): Likewise.
      * src/storage/storage_driver.c (storageDriverStartup): Likewise.
      * src/uml/uml_driver.c (TEMPDIR, umlStartup): Likewise.
      * src/util/hooks.c (LIBVIRT_HOOK_DIR): Likewise.
      * tools/virsh.c (main): Likewise.
      * docs/hooks.html.in: Likewise.
      0d5f54bb
  3. 07 7月, 2010 1 次提交
    • J
      cpu: Add support for CPU vendor · af53714f
      Jiri Denemark 提交于
      By specifying <vendor> element in CPU requirements a guest can be
      restricted to run only on CPUs by a given vendor. Host CPU vendor is
      also specified in capabilities XML.
      
      The vendor is checked when migrating a guest but it's not forced, i.e.,
      guests configured without <vendor> element can be freely migrated.
      af53714f
  4. 10 2月, 2010 1 次提交
    • D
      Remove virConnectPtr from CPU XML APIs · f430ddb6
      Daniel P. Berrange 提交于
      The virConnectPtr is no longer required for error reporting since
      that is recorded in a thread local. Remove use of virConnectPtr
      from all APIs in cpu_conf.{h,c} and update all callers to
      match
      f430ddb6
  5. 09 2月, 2010 2 次提交
  6. 23 12月, 2009 1 次提交
  7. 22 12月, 2009 1 次提交
  8. 18 12月, 2009 1 次提交
    • J
      Adds CPU selection infrastructure · 7286882c
      Jiri Denemark 提交于
      Each driver supporting CPU selection must fill in host CPU capabilities.
      When filling them, drivers for hypervisors running on the same node as
      libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers,
      such as VMware, need to implement their own way of getting such data.
      Raw data can be decoded into virCPUDefPtr using cpuDecode() function.
      
      When implementing virConnectCompareCPU(), a hypervisor driver can just
      call cpuCompareXML() function with host CPU capabilities.
      
      For each guest for which a driver supports selecting CPU models, it must
      set the appropriate feature in guest's capabilities:
      
          virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0)
      
      Actions needed when a domain is being created depend on whether the
      hypervisor understands raw CPU data (currently CPUID for i686, x86_64
      architectures) or symbolic names has to be used.
      
      Typical use by hypervisors which prefer CPUID (such as VMware and Xen):
      
      - convert guest CPU configuration from domain's XML into a set of raw
        data structures each representing one of the feature policies:
      
          cpuEncode(conn, architecture, guest_cpu_config,
                    &forced_data, &required_data, &optional_data,
                    &disabled_data, &forbidden_data)
      
      - create a mask or whatever the hypervisor expects to see and pass it
        to the hypervisor
      
      Typical use by hypervisors with symbolic model names (such as QEMU):
      
      - get raw CPU data for a computed guest CPU:
      
          cpuGuestData(conn, host_cpu, guest_cpu_config, &data)
      
      - decode raw data into virCPUDefPtr with a possible restriction on
        allowed model names:
      
          cpuDecode(conn, guest, data, n_allowed_models, allowed_models)
      
      - pass guest->model and guest->features to the hypervisor
      
      * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c
        src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h
        src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h
      * configure.in: check for CPUID instruction
      * src/Makefile.am: glue the new files in
      * src/libvirt_private.syms: add new private symbols
      * po/POTFILES.in: add new cpu files containing translatable strings
      7286882c