1. 12 5月, 2015 1 次提交
  2. 11 5月, 2015 8 次提交
  3. 08 5月, 2015 1 次提交
    • C
      caps: Fix regression defaulting to host arch · 8910e063
      Cole Robinson 提交于
      My commit 747761a7 (v1.2.15 only) dropped this bit of logic when filling
      in a default arch in the XML:
      
      -    /* First try to find one matching host arch */
      -    for (i = 0; i < caps->nguests; i++) {
      -        if (caps->guests[i]->ostype == ostype) {
      -            for (j = 0; j < caps->guests[i]->arch.ndomains; j++) {
      -                if (caps->guests[i]->arch.domains[j]->type == domain &&
      -                    caps->guests[i]->arch.id == caps->host.arch)
      -                    return caps->guests[i]->arch.id;
      -            }
      -        }
      -    }
      
      That attempt to match host.arch is important, otherwise we end up
      defaulting to i686 on x86_64 host for KVM, which is not intended.
      Duplicate it in the centralized CapsLookup function.
      
      Additionally add some testcases that would have caught this.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1219191
      8910e063
  4. 05 5月, 2015 2 次提交
    • L
      conf: Add the cpu duplicate use check for vm numa settings · 8fedbbdb
      Luyao Huang 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1176020
      
      We had a check for the vcpu count total number in <numa>
      before, however this check is not good enough. There are
      some examples:
      
      1. one of cpu id is out of maxvcpus, can set success(cpu count = 5 < 10):
      
      <vcpu placement='static'>10</vcpu>
      <cell id='0' cpus='0-3,100' memory='512000' unit='KiB'/>
      
      2. use the same cpu in 2 cell, can set success(cpu count = 8 < 10):
      <vcpu placement='static'>10</vcpu>
      <cell id='0' cpus='0-3' memory='512000' unit='KiB'/>
      <cell id='1' cpus='0-3' memory='512000' unit='KiB'/>
      
      3. use the same cpu in 2 cell, cannot set success(cpu count = 11 > 10):
      <vcpu placement='static'>10</vcpu>
      <cell id='0' cpus='0-6' memory='512000' unit='KiB'/>
      <cell id='1' cpus='0-3' memory='512000' unit='KiB'/>
      
      Add a check for numa cpus, check if duplicate use one cpu in more
      than one cell.
      Signed-off-by: NLuyao Huang <lhuang@redhat.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      8fedbbdb
    • M
      Introduce GIC feature · 921c52b0
      Michal Privoznik 提交于
      Some platforms, like aarch64, don't have APIC but GIC. So there's
      no reason to have <apic/> feature turned on. However, we are
      still missing <gic/> feature. This commit introduces the feature
      to XML parser and formatter, adds documentation and updates RNG
      schema.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      921c52b0
  5. 04 5月, 2015 1 次提交
  6. 29 4月, 2015 2 次提交
  7. 28 4月, 2015 11 次提交
    • J
      conf: Resolve some Coverity errors · e505591e
      John Ferlan 提交于
      Resolve some Coverity errors with IOThread changes
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      e505591e
    • R
      conf: explicitly initialize 'cpumask' variable · fb9da19e
      Roman Bogorodskiy 提交于
      Build with clang fails with:
      
        CC       conf/libvirt_conf_la-domain_conf.lo
        conf/domain_conf.c:13377:9: error: variable 'cpumask' is used
        uninitialized whenever 'if' condition is true
        [-Werror,-Wsometimes-uninitialized]
            if (!(tmp = virXMLPropString(node, "cpuset"))) {
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      and many other similar errors regarding the 'cpuset' variable.
      
      Fix by explicitly initializing it with NULL.
      fb9da19e
    • L
      network: check newDef for used bridge names in addition to def · 06313277
      Laine Stump 提交于
      If someone has updated a network to change its bridge name, but the
      network is still active (so that bridge name hasn't taken effect yet),
      we still want to disallow another network from taking that new name.
      06313277
    • L
      network: move auto-assign of bridge name from XML parser to net driver · a28d3e48
      Laine Stump 提交于
      We already check that any auto-assigned bridge device name for a
      virtual network (e.g. "virbr1") doesn't conflict with the bridge name
      for any existing libvirt network (via virNetworkSetBridgeName() in
      conf/network_conf.c).
      
      We also want to check that the name doesn't conflict with any bridge
      device created on the host system outside the control of libvirt
      (history: possibly due to the ploriferation of references to libvirt's
      bridge devices in HOWTO documents all around the web, it is not
      uncommon for an admin to manually create a bridge in their host's
      system network config and name it "virbrX"). To add such a check to
      virNetworkBridgeInUse() (which is called by virNetworkSetBridgeName())
      we would have to call virNetDevExists() (from util/virnetdev.c); this
      function calls ioctl(SIOCGIFFLAGS), which everyone on the mailing list
      agreed should not be done from an XML parsing function in the conf
      directory.
      
      To remedy that problem, this patch removes virNetworkSetBridgeName()
      from conf/network_conf.c and puts an identically functioning
      networkBridgeNameValidate() in network/bridge_driver.c (because it's
      reasonable for the bridge driver to call virNetDevExists(), although
      we don't do that yet because I wanted this patch to have as close to 0
      effect on function as possible).
      
      There are a couple of inevitable changes though:
      
      1) We no longer check the bridge name during
         virNetworkLoadConfig(). Close examination of the code shows that
         this wasn't necessary anyway - the only *correct* way to get XML
         into the config files is via networkDefine(), and networkDefine()
         will always call networkValidate(), which previously called
         virNetworkSetBridgeName() (and now calls
         networkBridgeNameValidate()). This means that the only way the
         bridge name can be unset during virNetworkLoadConfig() is if
         someone edited the config file on disk by hand (which we explicitly
         prohibit).
      
      2) Just on the off chance that somebody *has* edited the file by hand,
         rather than crashing when they try to start their malformed
         network, a check for non-NULL bridge name has been added to
         networkStartNetworkVirtual().
      
         (For those wondering why I don't instead call
         networkValidateBridgeName() there to set a bridge name if one
         wasn't present - the problem is that during
         networkStartNetworkVirtual(), the lock for the network being
         started has already been acquired, but the lock for the network
         list itself *has not* (because we aren't adding/removing a
         network). But virNetworkBridgeInuse() iterates through *all*
         networks (including this one) and locks each network as it is
         checked for a duplicate entry; it is necessary to lock each network
         even before checking if it is the designated "skip" network because
         otherwise some other thread might acquire the list lock and delete
         the very entry we're examining. In the end, permitting a setting of
         the bridge name during network start would require that we lock the
         entire network list during any networkStartNetwork(), which
         eliminates a *lot* of parallelism that we've worked so hard to
         achieve (it can make a huge difference during libvirtd startup). So
         rather than try to adjust for someone playing against the rules, I
         choose to instead give them the error they deserve.)
      
      3) virNetworkAllocateBridge() (now removed) would leak any "template"
         string set as the bridge name. Its replacement
         networkFindUnusedBridgeName() doesn't leak the template string - it
         is properly freed.
      a28d3e48
    • J
      qemu: Add support to Add/Delete IOThreads · a27ed6e7
      John Ferlan 提交于
      Add qemuDomainAddIOThread and qemuDomainDelIOThread in order to add or
      remove an IOThread to/from the host either for live or config optoins
      
      The implementation for the 'live' option will use the iothreadpids list
      in order to make decision, while the 'config' option will use the
      iothreadids list.  Additionally, for deletion each may have to adjust
      the iothreadpin list.
      
      IOThreads are implemented by qmp objects, the code makes use of the existing
      qemuMonitorAddObject or qemuMonitorDelObject APIs.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      a27ed6e7
    • J
      domain: Introduce virDomainIOThreadSchedDelId · c6e2dc80
      John Ferlan 提交于
      We're about to allow IOThreads to be deleted, but an iothreadid may be
      included in some domain thread sched, so add a new API to allow removing
      an iothread from some entry.
      
      Then during the writing of the threadsched data and an additional check
      to determine whether the bitmap is all clear before writing it out.
      c6e2dc80
    • J
      conf: Adjust the iothreadsched expectations · 4dec8a01
      John Ferlan 提交于
      With iothreadid's allowing any 'id' value for an iothread_id, the
      iothreadsched code needs a slight adjustment to allow for "any"
      unsigned int value in order to create the bitmap of ids that will
      have scheduler adjustments. Adjusted the doc description as well.
      4dec8a01
    • J
      Move iothreadspin information into iothreadids · b266486f
      John Ferlan 提交于
      Remove the iothreadspin array from cputune and replace with a cpumask
      to be stored in the iothreadids list.
      
      Adjust the test output because our printing goes in order of the iothreadids
      list now.
      b266486f
    • J
      conf: Move virDomainPinIsDuplicate and make static · b96254d4
      John Ferlan 提交于
      Since it's only ever referenced in domain_conf.c, make the function
      static, but also will need to move it to somewhere before it's referenced
      rather than forward referencing it.
      b96254d4
    • J
      qemu: Use domain iothreadids to IOThread's 'thread_id' · 8d4614a5
      John Ferlan 提交于
      Add 'thread_id' to the virDomainIOThreadIDDef as a means to store the
      'thread_id' as returned from the live qemu monitor data.
      
      Remove the iothreadpids list from _qemuDomainObjPrivate and replace with
      the new iothreadids 'thread_id' element.
      
      Rather than use the default numbering scheme of 1..number of iothreads
      defined for the domain, use the iothreadid's list for the iothread_id
      
      Since iothreadids list keeps track of the iothread_id's, these are
      now used in place of the many places where a for loop would "know"
      that the ID was "+ 1" from the array element.
      
      The new tests ensure usage of the <iothreadid> values for an exact number
      of iothreads and the usage of a smaller number of <iothreadid> values than
      iothreads that exist (and usage of the default numbering scheme).
      8d4614a5
    • J
      conf: Add new domain XML element 'iothreadids' · 93383c1f
      John Ferlan 提交于
      Adding a new XML element 'iothreadids' in order to allow defining
      specific IOThread ID's rather than relying on the algorithm to assign
      IOThread ID's starting at 1 and incrementing to iothreads count.
      
      This will allow future patches to be able to add new IOThreads by
      a specific iothread_id and of course delete any exisiting IOThread.
      
      Each iothreadids element will have 'n' <iothread> children elements
      which will have attribute "id".  The "id" will allow for definition
      of any "valid" (eg > 0) iothread_id value.
      
      On input, if any <iothreadids> <iothread>'s are provided, they will
      be marked so that we only print out what we read in.
      
      On input, if no <iothreadids> are provided, the PostParse code will
      self generate a list of ID's starting at 1 and going to the number
      of iothreads defined for the domain (just like the current algorithm
      numbering scheme).  A future patch will rework the existing algorithm
      to make use of the iothreadids list.
      
      On output, only print out the <iothreadids> if they were read in.
      93383c1f
  8. 27 4月, 2015 3 次提交
  9. 24 4月, 2015 5 次提交
  10. 22 4月, 2015 1 次提交
  11. 21 4月, 2015 5 次提交