1. 10 8月, 2015 10 次提交
    • L
      qemu: support new pci controller model "pcie-switch-upstream-port" · cb99086d
      Laine Stump 提交于
      this is backed by the qemu device x3130-upstream. It can only plug
      into a pcie-root-port or pcie-switch-downstream-port.
      cb99086d
    • L
      conf: new pci controller model "pcie-switch-upstream-port" · 38ea9515
      Laine Stump 提交于
      This controller can be connected only to a pcie-root-port or a
      pcie-switch-downstream-port (which will be added in a later patch),
      which is the reason for the new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
      32 ports (slot=0 to slot=31) on the downstream side, which can only
      have pci controllers of model "pcie-switch-downstream-port" plugged
      into them, which is the reason for the other new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
      38ea9515
    • L
      qemu: add capabilities bit for device x3130-upstream · 4cde7588
      Laine Stump 提交于
      This is the upstream part of a PCIe switch. It connects to a PCIe port
      (but not PCI) on the upstream side, and can have up to 31
      xio3130-downstream controllers (but no other types of devices)
      connected to its downstream side.
      
      This device will be used to implement the "pcie-switch-upstream-port"
      model of pci controller.
      4cde7588
    • L
      qemu: support new pci controller model "pcie-root-port" · 16328520
      Laine Stump 提交于
      This is backed by the qemu device ioh3420.
      
      chassis and port from the <target> subelement are used to store/set the
      respective qemu device options for the ioh3420. Currently, chassis is
      set to be the index of the controller, and port is set to
      "(slot << 3) + function" (per suggestion from Alex Williamson).
      16328520
    • 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 12 次提交