1. 24 1月, 2013 6 次提交
    • P
      capabilities: Switch CPU data in NUMA topology to a struct · 87b4c10c
      Peter Krempa 提交于
      This will allow storing additional topology data in the NUMA topology
      definition.
      
      This patch changes the storage type and fixes fallout of the change
      across the drivers using it.
      
      This patch also changes semantics of adding new NUMA cell information.
      Until now the data were re-allocated and copied to the topology
      definition. This patch changes the addition function to steal the
      pointer to a pre-allocated structure to simplify the code.
      87b4c10c
    • P
    • P
      schemas: Add schemas for more CPU topology information in the caps XML · 828820e2
      Peter Krempa 提交于
      This patch adds RNG schemas for adding more information in the topology
      output of the NUMA section in the capabilities XML.
      
      The added elements are designed to provide more information about the
      placement and topology of the processors in the system to management
      applications.
      
      A demonstration of supported XML added by this patch:
      <capabilities>
        <host>
          <topology>
            <cells num='3'>
              <cell id='0'>
                <cpus num='4'> <!-- this is node with Hyperthreading -->
                  <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/>
                  <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/>
                  <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/>
                  <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/>
                </cpus>
              </cell>
              <cell id='1'>
                <cpus num='4'> <!-- this is node with modules (Bulldozer) -->
                  <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/>
                  <cpu id='5' socket_id='0' core_id='3' siblings='4-5'/>
                  <cpu id='6' socket_id='0' core_id='4' siblings='6-7'/>
                  <cpu id='7' socket_id='0' core_id='5' siblings='6-7'/>
                </cpus>
               </cell>
              <cell id='2'>
                <cpus num='4'> <!-- this is a normal multi-core node -->
                  <cpu id='8' socket_id='1' core_id='0' siblings='8'/>
                  <cpu id='9' socket_id='1' core_id='1' siblings='9'/>
                  <cpu id='10' socket_id='1' core_id='2' siblings='10'/>
                  <cpu id='11' socket_id='1' core_id='3' siblings='11'/>
                </cpus>
               </cell>
            </cells>
          </topology>
        </host>
      </capabilities>
      
      The socket_id field represents identification of the physical socket the
      CPU is plugged in. This ID may not be identical to the physical socket
      ID reported by the kernel.
      
      The core_id identifies a core within a socket. Also this field may not
      accurately represent physical ID's.
      
      The core_id is guaranteed to be unique within a cell and a socket. There
      may be duplicates between sockets. Only cores sharing core_id within one
      cell and one socket can be considered as threads. Cores sharing core_id
      within sparate cells are distinct cores.
      
      The siblings field is a list of CPU id's the cpu id's the CPU is sibling
      with - thus a thread. The list is in the cpuset format.
      828820e2
    • P
      14940b5e
    • V
      S390: Enhance memballoon handling for virtio-s390 · 053e813a
      Viktor Mihajlovski 提交于
      The way in that memory balloon suppression was handled for S390
      is flawed for a number or reasons.
      1. Just preventing the default balloon to be created in the case
         of VIR_ARCH_S390[X] is not sufficient. An explicit memballoon
         element in the guest definition will still be honored, resulting
         both in a -balloon option and the allocation of a PCI bus address,
         neither being supported.
      2. Prohibiting balloon for S390 altogether at a domain_conf level
         is no good solution either as there's work in progress on the QEMU
         side to implement a virtio-balloon device, although in
         conjunction with a new machine type. Suppressing the balloon
         should therefore be done at the QEMU driver level depending
         on the present capabilities.
      
      Therefore we remove the conditional suppression of the default
      balloon in domain_conf.c.
      Further, we are claiming the memballoon device for virtio-s390
      during device address assignment to prevent it from being considered
      as a PCI device.
      Finally, we suppress the generation of the balloon command line option
      if this is a virtio-s390 machine.
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      053e813a
    • V
      qemu: Re-add driver unlock to qemuDomainSendKey · 7b3a9f75
      Viktor Mihajlovski 提交于
      Should have been done in commit 56fd5134 already, but was missed
      due to oversight: qemuDomainSendKey didn't release the driver lock
      in its cleanup section. This fixes an issue introduced by commit
      8c5d2bad.
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      7b3a9f75
  2. 23 1月, 2013 31 次提交
  3. 22 1月, 2013 3 次提交