1. 11 8月, 2015 24 次提交
    • M
      conf: Don't try formating non-existing addresses · 1f24c149
      Martin Kletzander 提交于
      Commit a6f9af82 added checking for address colisions between
      starting and ending addresses of forwarding addresses, but forgot that
      there might be no addresses set at all.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      1f24c149
    • A
      tests: Add a bunch of cpu test case for ppc64 · 818e68c5
      Andrea Bolognani 提交于
      The test cases cover the cpuCompare(), cpuBaseline() and
      cpuNodeData() implementation.
      818e68c5
    • A
      tests: Re-enable ppc64 cpu tests · 049df975
      Andrea Bolognani 提交于
      Now that all the changes have been implemented we can run the
      test cases once again, after updating them to reflect the new
      behaviour.
      049df975
    • A
      cpu: Forbid model fallback in the ppc64 driver · 344d1675
      Andrea Bolognani 提交于
      Unlike what happens on x86, on ppc64 you can't mix and match CPU
      features to obtain the guest CPU you want regardless of the host
      CPU, so the concept of model fallback doesn't apply.
      
      Make sure CPU definitions emitted by the driver, eg. as output of
      the cpuBaseline() and cpuUpdate() calls, reflect this fact.
      344d1675
    • A
      cpu: Implement backwards compatibility in the ppc64 driver · dee2247a
      Andrea Bolognani 提交于
      All previously recognized CPU models (POWER7_v2.1, POWER7_v2.3,
      POWER7+_v2.1 and POWER8_v1.0) are internally converted to the
      corrisponding generation name so that existing guests don't stop
      working.
      dee2247a
    • A
      cpu: Add POWER8NVL information to CPU map XML · 36300d2b
      Andrea Bolognani 提交于
      This is yet another variation of POWER8. The PVR information comes
      from arch/powerpc/kernel/cputable.c in the Linux kernel tree.
      36300d2b
    • A
      cpu: Parse and use PVR masks in the ppc64 driver · 5d0aa93c
      Andrea Bolognani 提交于
      Instead of relying on a hard-coded mask value, read it from the CPU
      map XML and use it when looking up models by PVR.
      5d0aa93c
    • A
      cpu: Simplify ppc64 part of CPU map XML · d87359af
      Andrea Bolognani 提交于
      Use multiple PVRs per CPU model to reduce the number of models we
      need to keep track of.
      
      Remove specific CPU models (eg. POWER7+_v2.1): the corresponding
      generic CPU model (eg. POWER7) should be used instead to ensure
      the guest can be booted on any compatible host.
      
      Get rid of all the entries that did not match any of the CPU
      models supported by QEMU, like power8 and power8e.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
      d87359af
    • A
      cpu: Support multiple PVRs in the ppc64 driver · 59fcc961
      Andrea Bolognani 提交于
      This will allow us to perform PVR matching more broadly, eg. consider
      both POWER8 and POWER8E CPUs to be the same even though they have
      different PVR values.
      59fcc961
    • A
      cpu: Align ppc64 CPU data with x86 · adb865df
      Andrea Bolognani 提交于
      Use a typedef instead of the plain struct and heap allocation. This
      will make it easier to extend the ppc64 specific CPU data later on.
      adb865df
    • A
      tests: Temporarily disable ppc64 cpu tests · 04f5a60d
      Andrea Bolognani 提交于
      The upcoming commits will make heavy modifications to the ppc64
      driver, split so that it's easier to review the changes.
      
      Instead of updating the test cases so that they pass, possibly
      only to update them again with the following commit, disable them
      for the time being.
      
      Another commit will update them all in one go once all required
      changes are in place.
      04f5a60d
    • A
      cpu: Use ppc64Compute() to implement ppc64DriverCompare() · d574094d
      Andrea Bolognani 提交于
      This ensures comparison of two CPU definitions will be consistent
      regardless of the fact that it is performed using cpuCompare() or
      cpuGuestData(). The x86 driver uses the same exact code.
      d574094d
    • A
      cpu: CPU model names have to match on ppc64 · 96b2c745
      Andrea Bolognani 提交于
      Limitations of the POWER architecture mean that you can't run
      eg. a POWER7 guest on a POWER8 host when using KVM. This applies
      to all guests, not just those using VIR_CPU_MATCH_STRICT in the
      CPU definition; in fact, exact and strict CPU matching are
      basically the same on ppc64.
      
      This means, of course, that hosts using different CPUs have to be
      considered incompatible as well.
      
      Change ppc64Compute(), called by cpuGuestData(), to reflect this
      fact and update test cases accordingly.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
      96b2c745
    • A
      cpu: Never skip CPU model name check in ppc64 driver · 8382136d
      Andrea Bolognani 提交于
      ppc64Compute(), called by cpuNodeData(), is used not only to retrieve
      the driver-specific data associated to a guest CPU definition, but
      also to check whether said guest CPU is compatible with the host CPU.
      
      If the user is not interested in the CPU data, it's perfectly fine
      to pass a NULL pointer instead of a return location, and the
      compatibility data returned should not be affected by this. One of
      the checks, specifically the one on CPU model name, was however
      only performed if the return location was non-NULL.
      8382136d
    • A
      tests: Improve result handling in cpuTestGuestData() · e5ef51a4
      Andrea Bolognani 提交于
      A test is considered successful if the obtained result matches
      the expected result: if that's not the case, whether because a
      test that was expected to succeed failed or because a test that
      was supposed to fail succeeded, then something's not right and
      we want the user to know about this.
      
      On the other hand, if a failure that's unrelated to the bits
      we're testing occurs, then the user should be notified even if
      the test was expected to fail.
      
      Use different values to tell these two situations apart.
      
      Fix a test case that was wrongly expected to fail as well.
      e5ef51a4
    • A
      tests: Remove unused file · 81a925e0
      Andrea Bolognani 提交于
      No functional changes.
      81a925e0
    • A
      cpu: Remove ISA information from CPU map XML · cb8c0e11
      Andrea Bolognani 提交于
      The information is not used anywhere in libvirt.
      
      No functional changes.
      cb8c0e11
    • A
      cpu: Reorder functions in the ppc64 driver · b85b51f2
      Andrea Bolognani 提交于
      Having the functions grouped together this way will avoid further
      shuffling around down the line.
      
      No functional changes.
      b85b51f2
    • A
      cpu: Simplify ppc64ModelFromCPU() · c238d16a
      Andrea Bolognani 提交于
      c238d16a
    • A
      cpu: Simplify NULL handling in ppc64 driver · 4590f067
      Andrea Bolognani 提交于
      Use briefer checks, eg. (!model) instead of (model == NULL), and
      avoid initializing to NULL a pointer that would be assigned in
      the first line of the function anyway.
      
      Also remove a pointless NULL assignment.
      
      No functional changes.
      4590f067
    • A
      cpu: Mark driver functions in ppc64 driver · 2686bf22
      Andrea Bolognani 提交于
      Use the ppc64Driver prefix for all functions that are used to
      fill in the cpuDriverPPC64 structure, ie. those that are going
      to be called by the generic CPU code.
      
      This makes it clear which functions are exported and which are
      implementation details; it also gets rid of the ambiguity that
      affected the ppc64DataFree() function which, despite what the
      name suggested, was not related to ppc64DataCopy() and could
      not be used to release the memory allocated for a
      virCPUppc64Data* instance.
      
      No functional changes.
      2686bf22
    • E
      admin: Drop 'internal.h' include from libvirt-admin.h · eefec56b
      Erik Skultety 提交于
      This is a public library, it shouldn't include anything that is
      internal. Including the library in it's current state to an example
      application fails the preprocessor phase.
      eefec56b
    • L
      qemu: fail on attempts to use <filterref> for non-tap network connections · f4f1d18d
      Laine Stump 提交于
      nwfilter uses iptables and ebtables, which only work properly on
      tap-based network connections (*not* on macvtap, for example), but we
      just ignore any <filterref> elements for other types of networks,
      potentially giving users a false sense of security.
      
      This patch checks the network type and fails/logs an error if any
      domain <interface> has a <filterref> when the connection isn't using a
      tap device.
      
      This resolves:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1180011
      f4f1d18d
    • L
      network: validate network NAT range · a6f9af82
      Laine Stump 提交于
      This patch modifies virSocketAddrGetRange() to function properly when
      the containing network/prefix of the address range isn't known, for
      example in the case of the NAT range of a virtual network (since it is
      a range of addresses on the *host*, not within the network itself). We
      then take advantage of this new functionality to validate the NAT
      range of a virtual network.
      
      Extra test cases are also added to verify that virSocketAddrGetRange()
      works properly in both positive and negative cases when the network
      pointer is NULL.
      
      This is the *real* fix for:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=985653
      
      Commits 1e334a and 48e8b9 had earlier been pushed as fixes for that
      bug, but I had neglected to read the report carefully, so instead of
      fixing validation for the NAT range, I had fixed validation for the
      DHCP range. sigh.
      a6f9af82
  2. 10 8月, 2015 16 次提交
    • M
    • M
      conf: Add ioeventfd option for controllers · 35eecdde
      Martin Kletzander 提交于
      This will be used with a virtio-scsi controller later on.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      35eecdde
    • M
      virNetDevBandwidthParseRate: Reject negative values · 2a5d3f22
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1022292
      
      The following XML really does not make any sense:
      
      <inbound average="-1" burst="-2" peak="-3" floor="-4"/>
      
      There can't be a negative packet rate. Well, so far we haven't
      assigned any meaning to it. So reject it unless users harm themselves,
      because otherwise we turn the negative numbers into really big values.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      2a5d3f22
    • C
      qemuMonitorOpenInternal: remove redundant code · 17cba9fb
      Cao jin 提交于
      There's no need to set mon->fd to a dummy value since
      it's initialized to proper value just a few lines below.
      Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
      17cba9fb
    • M
      rpc: Remove keepalive_required option · a8743c39
      Martin Kletzander 提交于
      Since its introduction in 2011 (particularly in commit f4324e32),
      the option doesn't work.  It just effectively disables all incoming
      connections.  That's because the client private data that contain the
      'keepalive_supported' boolean, are initialized to zeroes so the bool is
      false and the only other place where the bool is used is when checking
      whether the client supports keepalive.  Thus, according to the server,
      no client supports keepalive.
      
      Removing this instead of fixing it is better because a) apparently
      nobody ever tried it since 2011 (4 years without one month) and b) we
      cannot know whether the client supports keepalive until we get a ping or
      pong keepalive packet.  And that won't happen until after we dispatched
      the ConnectOpen call.
      
      Another two reasons would be c) the keepalive_required was tracked on
      the server level, but keepalive_supported was in private data of the
      client as well as the check that was made in the remote layer, thus
      making all other instances of virNetServer miss this feature unless they
      all implemented it for themselves and d) we can always add it back in
      case there is a request and a use-case for it.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      a8743c39
    • C
      fix typo in comments · b1ad57ec
      Cao jin 提交于
      Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
      b1ad57ec
    • M
      virDomainCoreDumpWithFormat: Mention enum for @dumpformat · bc359f77
      Michal Privoznik 提交于
      So the API takes @dumpformat argument. This is what makes it special
      when compared to virDomainCoreDump. The argument is there so that
      users can choose the format of resulting core dump file. And to ease
      them the choosing process we even have an enum with supported values
      across all the hypervisors. But we don't mention the enum in  the
      function description anywhere. Fix it!
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      bc359f77
    • L
      network: verify proper address family in updates to <host> and <range> · 6a21bc11
      Laine Stump 提交于
      By specifying parentIndex in a call to virNetworkUpdate(), it was
      possible to direct libvirt to add a dhcp range or static host of a
      non-matching address family to the <dhcp> element of an <ip>. For
      example, given:
      
       <ip address='192.168.122.1' netmask='255.255.255.0'/>
       <ip family='ipv6' address='2001:db6:ca3:45::1' prefix='64'/>
      
      you could provide a static host entry with an IPv4 address, and
      specify that it be added to the 2nd <ip> element (index 1):
      
        virsh net-update default add ip-dhcp-host --parent-index 1 \
        '<host mac="52:54:00:00:00:01" ip="192.168.122.45"/>'
      
      This would be happily added with no error (and no concern of any
      possible future consequences).
      
      This patch checks that any dhcp range or host element being added to a
      network ip's <dhcp> subelement has addresses of the same family as the
      ip element they are being added to.
      
      This resolves:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1184736
      6a21bc11
    • L
      qemu: support new pci controller model "pcie-switch-downstream-port" · 7d69387c
      Laine Stump 提交于
      This is backed by the qemu device xio3130-downstream. It can only be
      connected to a pcie-switch-upstream-port (x3130-upstream) on the
      upstream side.
      7d69387c
    • L
      conf: new pcie-controller model "pcie-switch-downstream-port" · 76379a6e
      Laine Stump 提交于
      This controller can be connected only to a port on a
      pcie-switch-upstream-port. It provides a single hotpluggable port that
      will accept any PCI or PCIe device, as well as any device requiring a
      pcie-*-port (the only current example of such a device is the
      pcie-switch-upstream-port).
      76379a6e
    • L
      qemu: add capabilities bit for device xio3130-downstream · ad1748a1
      Laine Stump 提交于
      The downstream ports of an x3130-upstream switch can each have one of
      these plugged into them (and that is the only place they can be
      connected). Each xio3130-downstream provides a single PCIe port that
      can have PCI or PCIe devices hotplugged into it. Apparently an entire
      set of x3130-upstream + several xio3130-downstreams can be hotplugged
      as a unit, but it's not clear to me yet how that would be done, since
      qemu only allows attaching a single device at a time.
      
      This device will be used to implement the
      "pcie-switch-downstream-port" model of pci controller.
      ad1748a1
    • 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