1. 10 8月, 2015 6 次提交
    • L
      conf: new pci controller model "pcie-root-port" · dce3b8be
      Laine Stump 提交于
      This controller can be connected (at domain startup time only - not
      hotpluggable) only to a port on the pcie root complex ("pcie-root" in
      libvirt config), hence the new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
      will accept any PCI or PCIe device.
      
      New attributes must be added to the controller <target> subelement for
      this - chassis and port are guest-visible option values that will be
      set by libvirt with values derived from the controller's index and pci
      address information.
      dce3b8be
    • L
      qemu: add capabilities bit for device ioh3420 · 408b100a
      Laine Stump 提交于
      This is a PCIE "root port". It connects only to a port of the
      integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and
      provides a single PCIe port that can have PCI or PCIe devices
      hotplugged into it.
      
      This device will be used to implement the "pcie-root-port" model of
      pci controller.
      408b100a
    • L
      qemu: implement <target chassisNr='n'/> subelement/attribute of <controller> · 18c10451
      Laine Stump 提交于
      This uses the new subelement/attribute in two ways:
      
      1) If a "pci-bridge" pci controller has no chassisNr attribute, it
      will automatically be set to the controller's index as soon as the
      controller's PCI address is known (during
      qemuDomainAssignPCIAddresses()).
      
      2) when creating the commandline for a pci-bridge device, chassisNr
      will be used to set qemu's chassis_nr option (rather than the previous
      practice of hard-coding it to the controller's index).
      18c10451
    • L
      conf: add new <target> subelement with chassisNr attribute to <controller> · 8dc88aee
      Laine Stump 提交于
      There are some configuration options to some types of pci controllers
      that are currently automatically derived from other parts of the
      controller's configuration. For example, in qemu a pci-bridge
      controller has an option that is called "chassis_nr"; up until now
      libvirt has always set chassis_nr to the index of the pci-bridge. So
      this:
      
        <controller type='pci' model='pci-bridge' index='2'/>
      
      will always result in:
      
        -device pci-bridge,chassis_nr=2,...
      
      on the qemu commandline. In the future we may decide there is a better
      way to derive that option, but even in that case we will need for
      existing domains to retain the same chassis_nr they were using in the
      past - that is something that is visible to the guest so it is part of
      the guest ABI and changing it would lead to problems for migrating
      guests (or just guests with very picky OSes).
      
      The <target> subelement has been added as a place to put the new
      "chassisNr" attribute that will be filled in by libvirt when it
      auto-generates the chassisNr; it will be saved in the config, then
      reused any time the domain is started:
      
        <controller type='pci' model='pci-bridge' index='2'>
          <model type='pci-bridge'/>
          <target chassisNr='2'/>
        </controller>
      
      The one oddity of all this is that if the controller configuration
      is changed (for example to change the index or the pci address
      where the controller is plugged in), the items in <target> will
      *not* be re-generated, which might lead to conflict. I can't
      really see any way around this, but fortunately if there is a
      material conflict qemu will let us know and we will pass that on
      to the user.
      8dc88aee
    • L
      qemu: implement <model> subelement to <controller> · 572ebdbc
      Laine Stump 提交于
      This patch provides qemu support for the contents of <model> in
      <controller> for the two existing PCI controller types that need it
      (i.e. the two controller types that are backed by a device that must
      be specified on the qemu commandline):
      
      1) pci-bridge - sets <model> name attribute default as "pci-bridge"
      
      2) dmi-to-pci-bridge - sets <model> name attribute default as
         "i82801b11-bridge".
      
      These both match current hardcoded practice.
      
      The defaults are set at the end of qemuDomainAssignPCIAddresses().
      This can't be done earlier because some of the options that will be
      autogenerated need full PCI address info for the controller, and
      because qemuDomainAssignPCIAddresses() might create extra controllers
      which would need default settings added, and that hasn't yet been done
      at the time the PostParse callbacks are being run.
      qemuDomainAssignPCIAddresses() is still called prior to the XML being
      written to disk, though, so the autogenerated defaults are persistent.
      
      qemu capabilities bits aren't checked when the domain is defined, but
      rather when the commandline is actually created (so the domain can
      possibly be defined on a host that doesn't yet have support for the
      given device, or a host different from the one where it will
      eventually be run). When the commandline is being generated we compare
      the modelName to known qemu device names implementing the given type
      of controller, and check the capabilities bit for that device.
      572ebdbc
    • L
      conf: add new <model> subelement with name attribute to <controller> · bf202510
      Laine Stump 提交于
      This new subelement is used in PCI controllers: the toplevel
      *attribute* "model" of a controller denotes what kind of PCI
      controller is being described, e.g. a "dmi-to-pci-bridge",
      "pci-bridge", or "pci-root". But in the future there will be different
      implementations of some of those types of PCI controllers, which
      behave similarly from libvirt's point of view (and so should have the
      same model), but use a different device in qemu (and present
      themselves as a different piece of hardware in the guest). In an ideal
      world we (i.e. "I") would have thought of that back when the pci
      controllers were added, and used some sort of type/class/model
      notation (where class was used in the way we are now using model, and
      model was used for the actual manufacturer's model number of a
      particular family of PCI controller), but that opportunity is long
      past, so as an alternative, this patch allows selecting a particular
      implementation of a pci controller with the "name" attribute of the
      <model> subelement, e.g.:
      
        <controller type='pci' model='dmi-to-pci-bridge' index='1'>
          <model name='i82801b11-bridge'/>
        </controller>
      
      In this case, "dmi-to-pci-bridge" is the kind of controller (one that
      has a single PCIe port upstream, and 32 standard PCI ports downstream,
      which are not hotpluggable), and the qemu device to be used to
      implement this kind of controller is named "i82801b11-bridge".
      
      Implementing the above now will allow us in the future to add a new
      kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge
      device, but instead uses something else (which doesn't yet exist, but
      qemu people have been discussing it), all without breaking existing
      configs.
      
      (note that for the existing "pci-bridge" type of PCI controller, both
      the model attribute and <model> name are 'pci-bridge'. This is just a
      coincidence, since it turns out that in this case the device name in
      qemu really is a generic 'pci-bridge' rather than being the name of
      some real-world chip)
      bf202510
  2. 09 8月, 2015 1 次提交
    • L
      conf: more useful error message when pci function is out of range · f8fe8f03
      Laine Stump 提交于
      If a pci address had a function number out of range, the error message
      would be:
      
        Insufficient specification for PCI address
      
      which is logged by virDevicePCIAddressParseXML() after
      virDevicePCIAddressIsValid returns a failure.
      
      This patch enhances virDevicePCIAddressIsValid() to optionally report
      the error itself (since it is the place that decides which part of the
      address is "invalid"), and uses that feature when calling from
      virDevicePCIAddressParseXML(), so that the error will be more useful,
      e.g.:
      
        Invalid PCI address function=0x8, must be <= 7
      
      Previously, virDevicePCIAddressIsValid didn't check for the
      theoretical limits of domain or bus, only for slot or function. While
      adding log messages, we also correct that ommission. (The RNG for PCI
      addresses already enforces this limit, which by the way means that we
      can't add any negative tests for this - as far as I know our
      domainschematest has no provisions for passing XML that is supposed to
      fail).
      
      Note that virDevicePCIAddressIsValid() can only check against the
      absolute maximum attribute values for *any* possible PCI controller,
      not for the actual maximums of the specific controller that this
      device is attaching to; fortunately there is later more specific
      validation for guest-side PCI addresses when building the set of
      assigned PCI addresses. For host-side PCI addresses (e.g. for
      <hostdev> and for network device pools), we rely on the error that
      will be logged when it is found that the device doesn't actually
      exist.
      
      This resolves:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1004596
      f8fe8f03
  3. 07 8月, 2015 3 次提交
  4. 06 8月, 2015 7 次提交
  5. 05 8月, 2015 7 次提交
  6. 04 8月, 2015 14 次提交
  7. 03 8月, 2015 2 次提交
    • A
      nodeinfo: Fix build failure when KVM headers are not available · 88c4c32a
      Andrea Bolognani 提交于
      Compiler error:
      
        ../../src/nodeinfo.c: In function 'nodeGetThreadsPerSubcore':
        ../../src/nodeinfo.c:2393: error: label 'out' defined but not used [-Wunused-label]
        ../../src/nodeinfo.c:2352: error: unused parameter 'arch' [-Wunused-parameter]
      88c4c32a
    • M
      qemu: Remove double unlock for domains · c43c661f
      Martin Kletzander 提交于
      The virDomainObjListRemove() function unlocks a domain that it's given
      due to legacy code.  And because of that code, which should be
      refactored, that last virObjectUnlock() cannot be just removed.  So
      instead, lock it right back for qemu for now.  All calls to
      qemuDomainRemoveInactive() are followed by code that unlocks the domain
      again, plus the domain should be locked during qemuDomainObjEndJob(), so
      the right place to lock it is right after virDomainObjListRemove().
      
      The only place where this would cause a problem is the autodestroy
      callback, so we need to get another reference there and uref+unlock it
      afterwards.  Luckily, returning NULL from that function doesn't mean an
      error, and only means that it doesn't need to be unlocked anymore.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      c43c661f