1. 29 3月, 2016 2 次提交
    • J
      docs: Update the hyperv feature qemu supported version · 53d2ca5f
      John Ferlan 提交于
      In order to follow recent comments which indicate support for specific
      feature bits are supported by a specific QEMU version add the version
      from whence the relaxed, vapic, and spinlocks support was added.
      53d2ca5f
    • M
      conf: qemu: Add support for more HyperV Enlightenment features · 7068b56c
      Maxim Nestratov 提交于
      This patch adds support for "vpindex", "runtime", "synic",
      "stimer", and "vendor_id" features available in qemu 2.5+.
      
      - When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX
      to get virtual processor ID.
      
      - Hyper-V "runtime" enlightement feature allows to use MSR
      HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes
      running guest code, as well as the time the hypervisor spends running
      code on behalf of that guest.
      
      - Hyper-V "synic" stands for Synthetic Interrupt Controller, which is
      lapic extension controlled via MSRs.
      
      - Hyper-V "stimer" switches on Hyper-V SynIC timers MSR's support.
      Guest can setup and use fired by host events (SynIC interrupt and
      appropriate timer expiration message) as guest clock events
      
      - Hyper-V "reset" allows guest to reset VM.
      
      - Hyper-V "vendor_id" exposes hypervisor vendor id to guest.
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      7068b56c
  2. 21 3月, 2016 1 次提交
    • J
      conf: add 'state' attribute to <hap> feature · 9d243e08
      Jim Fehlig 提交于
      Most hypervisors use Hardware Assisted Paging by default and don't
      require specifying the feature in domain conf. But some hypervisors
      support disabling HAP on a per-domain basis. To enable HAP by default
      yet provide a knob to disable it, extend the <hap> feature with a
      'state=on|off' attribute, similar to <pvspinlock> and <vmport> features.
      
      In the absence of <hap>, the hypervisor default (on) is used. <hap>
      without the state attribute would be the same as <hap state='on'/> for
      backwards compatibility. And of course <hap state='off'/> disables hap.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      9d243e08
  3. 17 3月, 2016 1 次提交
  4. 10 3月, 2016 1 次提交
    • D
      conf: allow use of a logfile with chardev backends · 00ce10c7
      Daniel P. Berrange 提交于
      Extend the chardev source XML so that there is a new optional
      <log/> element, which is applicable to all character device
      backend types. For example, to log output of a TCP backed
      serial port
      
          <serial type='tcp'>
            <source mode='connect' host='127.0.0.1' service='9999'/>
            <protocol type='raw'/>
            <log file='/var/log/libvirt/qemu/demo-serial0.log' append='on'/>
            <target port='0'/>
          </serial>
      
      Not all hypervisors will support use of logfiles.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      00ce10c7
  5. 01 3月, 2016 4 次提交
  6. 26 2月, 2016 1 次提交
  7. 20 2月, 2016 1 次提交
    • A
      docs: List possible GIC versions · ff0e2ebd
      Andrea Bolognani 提交于
      Recent changes to the handling of GIC version, specifically commit
      2a7b11ea, have clearly defined what values are acceptable for the
      version attribute of the <gic> element. Update the documentation
      accordingly.
      ff0e2ebd
  8. 15 2月, 2016 1 次提交
  9. 12 1月, 2016 1 次提交
    • D
      conf: introduce 'autodeflate' attribute for memballoon device · 7bf3198d
      Dmitry Andreev 提交于
      Excessive memory balloon inflation can cause invocation of OOM-killer,
      when Linux is under severe memory pressure. QEMU memballoon device
      has a feature to release some memory at the last moment before some
      process will be get killed by OOM-killer.
      
      Introduce a new optional balloon device attribute 'autodeflate' to
      enable or disable this feature.
      7bf3198d
  10. 06 1月, 2016 1 次提交
    • W
      rbd: Do not append Ceph monitor port number 6789 if not provided · 6343018f
      Wido den Hollander 提交于
      If no port number was provided for a storage pool libvirt defaults to
      port 6789; however, librbd/librados already default to 6789 when no port
      number is provided.
      
      In the future Ceph will switch to a new port for the Ceph monitors since
      port 6789 is already assigned to a different application by IANA.
      
      Port 6789 is assigned to SMC-HTTPS and Ceph now has port 3300 assigned as
      the 'Ceph monitor' port.
      
      In this case it is the best solution to not hardcode any port number into
      libvirt and let librados handle the connection.
      
      Only if a user specifies a different port number we pass it down to librados,
      otherwise we leave it blank.
      Signed-off-by: NWido den Hollander <wido@widodh.nl>
      
      merge
      6343018f
  11. 05 1月, 2016 1 次提交
  12. 30 11月, 2015 2 次提交
  13. 27 11月, 2015 1 次提交
  14. 25 11月, 2015 2 次提交
    • D
      Allow multiple panic devices · 59fc0d06
      Dmitry Andreev 提交于
      'model' attribute was added to a panic device but only one panic
      device is allowed. This patch changes panic device presence
      from 'optional' to 'zeroOrMore'.
      59fc0d06
    • D
      conf: add 'model' attribute for panic device with values isa, pseries, hyperv · 658ec27f
      Dmitry Andreev 提交于
      Libvirt already has two types of panic devices - pvpanic and pSeries firmware.
      This patch introduces the 'model' attribute and a new type of panic device.
      
      'isa' model is for ISA pvpanic device.
      'pseries' model is a default value for pSeries guests.
      'hyperv' model is the new type. It's used for Hyper-V crash.
      
      Schema and docs are updated for the new attribute.
      658ec27f
  15. 18 11月, 2015 1 次提交
  16. 06 10月, 2015 1 次提交
    • C
      docs: domain: Show canonical pvspinlock XML · bdcc2f80
      Cole Robinson 提交于
      The example pvspinlock XML is:
      
        <pvspinlock/>
      
      While this is accepted by libvirt and works correctly, it's currently
      always output as a tristate like
      
        <pvspinlock state='on'/>
      
      So document that format instead
      bdcc2f80
  17. 02 9月, 2015 1 次提交
    • J
      qemu: add udp interface support · 5c668a78
      Jonathan Toppins 提交于
      Adds a new interface type using UDP sockets, this seems only applicable
      to QEMU but have edited tree-wide to support the new interface type.
      
      The interface type required the addition of a "localaddr" (local
      address), this then maps into the following xml and qemu call.
      
      <interface type='udp'>
        <mac address='52:54:00:5c:67:56'/>
        <source address='127.0.0.1' port='11112'>
          <local address='127.0.0.1' port='22222'/>
        </source>
        <model type='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
      </interface>
      
      QEMU call:
      	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222
      
      Notice the xml "local" entry becomes the "localaddr" for the qemu call.
      
      reference:
      http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      5c668a78
  18. 25 8月, 2015 1 次提交
  19. 10 8月, 2015 6 次提交
    • 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
    • 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
      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
      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
      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
      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
  20. 04 8月, 2015 2 次提交
  21. 17 7月, 2015 1 次提交
  22. 09 7月, 2015 1 次提交
  23. 28 6月, 2015 1 次提交
  24. 27 6月, 2015 3 次提交
    • J
      docs: Clarification for when allowed to use 'lun' for "volume" · 91b96438
      John Ferlan 提交于
      While re-reading what I wrote for commit id '785a8940', I realized
      I needed to clarify that being able to present as a 'lun', the mode
      property for the pool source element needed to be "host" (or empty)
      and not "direct".
      
      It was described correctly later in the mode host description, but
      this just ensures it's not missed here as well.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      91b96438
    • L
      docs: document when pcie-root/dmi-to-pci-bridge support was added · 10e207bb
      Laine Stump 提交于
      Also move the mention of version numbers for the various PCI
      controller models up to the end of the sentence where they are first
      given, to avoid confusion.
      10e207bb
    • L
      qemu: always permit PCI devices to be manually assigned to a PCIe bus · 1e15be1b
      Laine Stump 提交于
      When support for the pcie-root and dmi-to-pci-bridge buses on a Q35
      machinetype was added, I was concerned that even though qemu at the
      time allowed plugging a PCI device into a PCIe port, that it might not
      be supported in the future. To prevent painful backtracking in the
      possible future where this happened, I disallowed such connections
      except in a few specific cases requested by qemu developers (indicated
      in the code with the flag VIR_PCI_CONNECT_TYPE_EITHER_IF_CONFIG).
      
      Now that a couple years have passed, there is a clear message from
      qemu that there is no danger in allowing PCI devices to be plugged
      into PCIe ports. This patch eliminates
      VIR_PCI_CONNECT_TYPE_EITHER_IF_CONFIG and changes the code to always
      allow PCI->PCIe or PCIe->PCI connection *when the PCI address is
      specified in the config. (For newly added devices that haven't yet
      been given a PCI address, the auto-placement still prefers using the
      correct type of bus).
      1e15be1b
  25. 24 6月, 2015 2 次提交