1. 15 11月, 2016 8 次提交
    • L
      qemu: assign e1000e network devices to PCIe slots when appropriate · 9dfe733e
      Laine Stump 提交于
      The e1000e is an emulated network device based on the Intel 82574,
      present in qemu 2.7.0 and later. Among other differences from the
      e1000, it presents itself as a PCIe device rather than legacy PCI. In
      order to get it assigned to a PCIe controller, this patch updates the
      flags setting for network devices when the model name is "e1000e".
      
      (Note that for some reason libvirt has never validated the network
      device model names other than to check that there are no dangerous
      characters in them. That should probably change, but is the subject of
      another patch.)
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1343094
      9dfe733e
    • L
      qemu: assign virtio devices to PCIe slot when appropriate · c7fc151e
      Laine Stump 提交于
      libvirt previously assigned nearly all devices to a "hotpluggable"
      legacy PCI slot even on machines with a PCIe root bus (and even though
      most such machines don't even support hotplug on legacy PCI slots!)
      Forcing all devices onto legacy PCI slots means that the domain will
      need a dmi-to-pci-bridge (to convert from PCIe to legacy PCI) and a
      pci-bridge (to provide hotpluggable legacy PCI slots which, again,
      usually aren't hotpluggable anyway).
      
      To help reduce the need for these legacy controllers, this patch tries
      to assign virtio-1.0-capable devices to PCIe slots whenever possible,
      by setting appropriate connectFlags in
      virDomainCalculateDevicePCIConnectFlags(). Happily, when that function
      was written (just a few commits ago) it was created with a
      "virtioFlags" argument, set by both of its callers, which is the
      proper connectFlags to set for any virtio-*-pci device - depending on
      the arch/machinetype of the domain, and whether or not the qemu binary
      supports virtio-1.0, that flag will have either been set to PCI or
      PCIe. This patch merely enables the functionality by setting the flags
      for the device to whatever is in virtioFlags if the device is a
      virtio-*-pci device.
      
      NB: the first virtio video device will be placed directly on bus 0
      slot 1 rather than on a pcie-root-port due to the override for primary
      video devices in qemuDomainValidateDevicePCISlotsQ35(). Whether or not
      to change that is a topic of discussion, but this patch doesn't change
      that particular behavior.
      
      NB2: since the slot must be hotpluggable, and pcie-root (the PCIe root
      complex) does *not* support hotplug, this means that suitable
      controllers must also be in the config (i.e. either pcie-root-port, or
      pcie-downstream-port). For now, libvirt doesn't add those
      automatically, so if you put virtio devices in a config for a qemu
      that has PCIe-capable virtio devices, you'll need to add extra
      pcie-root-ports yourself. That requirement will be eliminated in a
      future patch, but for now, it's simple to do this:
      
         <controller type='pci' model='pcie-root-port'/>
         <controller type='pci' model='pcie-root-port'/>
         <controller type='pci' model='pcie-root-port'/>
         ...
      
      Partially Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1330024
      c7fc151e
    • L
      qemu: set pciConnectFlags to 0 instead of PCI|HOTPLUGGABLE if device isn't PCI · b27375a9
      Laine Stump 提交于
      This patch cleans up the connect flags for certain types/models of
      devices that aren't PCI to return 0. In the future that may be used as
      an indicator to the caller about whether or not a device needs a PCI
      address. For now it's just ignored, except for in
      virDomainPCIAddressEnsureAddr() - called during device hotplug - (and
      in some cases actually needs to be re-set to PCI|HOTPLUGGABLE just in
      case someone (in some old config) has manually set a PCI address for a
      device that isn't PCI.
      b27375a9
    • L
      qemu: set/use proper pciConnectFlags during hotplug · abb7a4bd
      Laine Stump 提交于
      Before now, all the qemu hotplug functions assumed that all devices to
      be hotplugged were legacy PCI endpoint devices
      (VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
      devices *are* legacy PCI endpoint devices on x86/440fx machinetypes,
      and hotplug didn't work properly on machinetypes using PCIe anyway
      (hotplugging onto a legacy PCI slot doesn't work, and until commit
      b87703cf any attempt to manually specify a PCIe address for a
      hotplugged device would be erroneously rejected).
      
      This patch makes all qemu hotplug operations honor the pciConnectFlags
      set by the single all-knowing function
      qemuDomainDeviceCalculatePCIConnectFlags(). This is done in 3 steps,
      but in a single commit since we would have to touch the other points
      at each step anyway:
      
      1) add a flags argument to the hypervisor-agnostic
      virDomainPCIAddressEnsureAddr() (previously it hardcoded
      ..._PCI_DEVICE)
      
      2) add a new qemu-specific function qemuDomainEnsurePCIAddress() which
      gets the correct pciConnectFlags for the device from
      qemuDomainDeviceConnectFlags(), then calls
      virDomainPCIAddressEnsureAddr().
      
      3) in qemu_hotplug.c replace all calls to
      virDomainPCIAddressEnsureAddr() with calls to
      qemuDomainEnsurePCIAddress()
      
      So in effect, we're putting a "shim" on top of all calls to
      virDomainPCIAddressEnsureAddr() that sets the right pciConnectFlags.
      abb7a4bd
    • L
      qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses · 7f784f57
      Laine Stump 提交于
      Set pciConnectFlags in each device's DeviceInfo and then use those
      flags later when validating existing addresses in
      qemuDomainCollectPCIAddress() and when assigning new addresses with
      qemuDomainPCIAddressReserveNextAddr() (rather than scattering the
      logic about which devices need which type of slot all over the place).
      
      Note that the exact flags set by
      qemuDomainDeviceCalculatePCIConnectFlags() are different from the
      flags previously set manually in qemuDomainCollectPCIAddress(), but
      this doesn't matter because all validation of addresses in that case
      ignores the setting of the HOTPLUGGABLE flag, and treats PCIE_DEVICE
      and PCI_DEVICE the same (this lax checking was done on purpose,
      because there are some things that we want to allow the user to
      specify manually, e.g. assigning a PCIe device to a PCI slot, that we
      *don't* ever want libvirt to do automatically. The flag settings that
      we *really* want to match are 1) the old flag settings in
      qemuDomainAssignDevicePCISlots() (which is HOTPLUGGABLE | PCI_DEVICE
      for everything except PCI controllers) and 2) the new flag settings
      done by qemuDomainDeviceCalculatePCIConnectFlags() (which are
      currently exactly that - HOTPLUGGABLE | PCI_DEVICE for everything
      except PCI controllers).
      7f784f57
    • L
      qemu: new functions to calculate/set device pciConnectFlags · bd776c2b
      Laine Stump 提交于
      The lowest level function of this trio
      (qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single
      authority for the virDomainPCIConnectFlags to use for any given device
      using a particular arch/machinetype/qemu-binary.
      
      qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a
      single device (unless it has no virDomainDeviceInfo, in which case
      it's a NOP).
      
      qemuDomainFillAllPCIConnectFlags() sets info->pciConnectFlags in all
      devices that have a virDomainDeviceInfo
      
      The latter two functions aren't called anywhere yet. This commit is
      just making them available. Later patches will replace all the current
      hodge-podge of flag settings with calls to this single authority.
      bd776c2b
    • L
      qemu: new functions qemuDomainMachineHasPCI[e]Root() · 50adb8a6
      Laine Stump 提交于
      These functions provide a simple one line method of learning if the
      current domain has a pci-root or pcie-root bus.
      50adb8a6
    • P
      vz: fixed migration in p2p mode · 4f949f74
      Pavel Glushchak 提交于
      dom xml generated on begin step should be passed
      to perform step in VIR_MIGRATE_PARAM_DEST_XML parameter.
      Otherwise 'XML error: failed to parse xml document' is
      raised on destination host as dom xml is NULL.
      Signed-off-by: NPavel Glushchak <pglushchak@virtuozzo.com>
      4f949f74
  2. 14 11月, 2016 31 次提交
  3. 13 11月, 2016 1 次提交