Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 7月, 2017 1 次提交
  3. 11 7月, 2017 4 次提交
  5. 20 6月, 2017 1 次提交
  7. 13 6月, 2017 3 次提交
  9. 08 6月, 2017 3 次提交
  11. 26 5月, 2017 1 次提交
  13. 16 5月, 2017 2 次提交
  15. 15 5月, 2017 2 次提交
  17. 21 4月, 2017 1 次提交
    • M
      conf, docs: Add support for coalesce setting(s) · 523c9960
      由 Martin Kletzander 提交于 
      We are currently parsing only rx/frames/max because that's the only
value that makes sense for us.  The tun device just added support for
this one and the others are only supported by hardware devices which
we don't need to worry about as the only way we'd pass those to the
domain is using <hostdev/> or <interface type='hostdev'/>.  And in
those cases the guest can modify the settings itself.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      523c9960
  19. 11 4月, 2017 2 次提交
  21. 04 4月, 2017 1 次提交
  23. 27 3月, 2017 1 次提交
  25. 17 3月, 2017 2 次提交
  27. 15 3月, 2017 3 次提交
    • M
      qemu: Introduce label-size for NVDIMMs · e433546b
      由 Michal Privoznik 提交于 
      For NVDIMM devices it is optionally possible to specify the size
of internal storage for namespaces. Namespaces are a feature that
allows users to partition the NVDIMM for different uses.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      e433546b
    • M
      conf: Introduce @access to <memory/> · 80af11d3
      由 Michal Privoznik 提交于 
      Now that NVDIMM has found its way into libvirt, users might want
to fine tune some settings for each module separately. One such
setting is 'share=on|off' for the memory-backend-file object.
This setting - just like its name suggest already - enables
sharing the nvdimm module with other applications. Under the hood
it controls whether qemu mmaps() the file as MAP_PRIVATE or
MAP_SHARED.

Yet again, we have such config knob in domain XML, but it's just
an attribute to numa <cell/>. This does not give fine enough
tuning on per-memdevice basis so we need to have the attribute
for each device too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      80af11d3
    • M
      Introduce NVDIMM memory model · b4e8a49f
      由 Michal Privoznik 提交于 
      NVDIMM is new type of memory introduced into QEMU 2.6. The idea
is that we have a Non-Volatile memory module that keeps the data
persistent across domain reboots.

At the domain XML level, we already have some representation of
'dimm' modules. Long story short, NVDIMM will utilize the
existing <memory/> element that lives under <devices/> by adding
a new attribute 'nvdimm' to the existing @model and introduce a
new <path/> element for <source/> while reusing other fields. The
resulting XML would appear as:

    <memory model='nvdimm'>
      <source>
        <path>/tmp/nvdimm</path>
      </source>
      <target>
        <size unit='KiB'>523264</size>
        <node>0</node>
      </target>
      <address type='dimm' slot='0'/>
    </memory>

So far, this is just a XML parser/formatter extension. QEMU
driver implementation is in the next commit.

For more info on NVDIMM visit the following web page:

    http://pmem.io/Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      b4e8a49f
  29. 24 2月, 2017 2 次提交
  31. 09 2月, 2017 1 次提交
    • J
      conf: Add new xml elements for file memorybacking support · bc6d3121
      由 Jaroslav Safka 提交于 
      This part introduces new xml elements for file based
memorybacking support and their parsing.
(It allows vhost-user to be used without hugepages.)

New xml elements:
<memoryBacking>
  <source type="file|anonymous"/>
  <access mode="shared|private"/>
  <allocation mode="immediate|ondemand"/>
</memoryBacking>
      bc6d3121
  33. 26 1月, 2017 1 次提交
  35. 20 1月, 2017 1 次提交
    • M
      qemu: set default vhost-user ifname · 57b5e27d
      由 Michal Privoznik 提交于 
      Based on work of Mehdi Abaakouk <sileht@sileht.net>.

When parsing vhost-user interface XML and no ifname is found we
can try to fill it in in post parse callback. The way this works
is we try to make up interface name from given socket path and
then ask openvswitch whether it knows the interface.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      57b5e27d
  37. 11 1月, 2017 2 次提交
    • L
      conf: aggregate multiple pcie-root-ports onto a single slot · 147ebe6d
      由 Laine Stump 提交于 
      Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so
that they will be assigned to all the functions on a slot.

Some qemu test case outputs had to be adjusted due to the
pcie-root-ports now being put on multiple functions.
      147ebe6d
    • L
      qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed · 8f400871
      由 Laine Stump 提交于 
      If there are multiple devices assigned to the different functions of a
single PCI slot, they will not work properly if the device at function
0 doesn't have its "multi" attribute turned on, so it makes sense for
libvirt to turn it on during PCI address assignment. Setting multi
then assures that the new setting is stored in the config (so it will
be used next time the domain is started), preventing any potential
problems in the case that a future change in the configuration
eliminates the devices on all non-0 functions (multi will still be set
for function 0 even though it is the only function in use on the slot,
which has no useful purpose, but also doesn't cause any problems).

(NB: If we were to instead just decide on the setting for
multifunction at runtime, a later removal of the non-0 functions of a
slot would result in a silent change in the guest ABI for the
remaining device on function 0 (although it may seem like an
inconsequential guest ABI change, it *is* a guest ABI change to turn
off the multi bit).)
      8f400871
  39. 10 1月, 2017 1 次提交
    • A
      qemu: Use virtio-pci by default for mach-virt guests · 1d845463
      由 Andrea Bolognani 提交于 
      virtio-pci is the way forward for aarch64 guests: it's faster
and less alien to people coming from other architectures.
Now that guest support is finally getting there (Fedora 24,
CentOS 7.3, Ubuntu 16.04 and Debian testing all support
virtio-pci out of the box), we'd like to start using it by
default instead of virtio-mmio.

Users and applications can already opt-in by explicitly using

  <address type='pci'/>

inside the relevant elements, but that's kind of cumbersome and
requires all users and management applications to adapt, which
we'd really like to avoid.

What we can do instead is use virtio-mmio only if the guest
already has at least one virtio-mmio device, and use virtio-pci
in all other situations.

That means existing virtio-mmio guests will keep using the old
addressing scheme, and new guests will automatically be created
using virtio-pci instead. Users can still override the default
in either direction.

Existing tests such as aarch64-aavmf-virtio-mmio and
aarch64-virtio-pci-default already cover all possible
scenarios, so no additions to the test suites are necessary.
      1d845463
  41. 06 12月, 2016 1 次提交
  43. 25 11月, 2016 1 次提交
    • E
      conf: Wire up the vhost-scsi connection from/to XML · ae5d30a0
      由 Eric Farman 提交于 
      With the QEMU components in place, provide the XML parsing to
invoke that code when given the following XML snippet:

    <hostdev mode='subsystem' type='scsi_host'>
      <source protocol='vhost' wwpn='naa.501234567890abcd'/>
    </hostdev>

An optional address element can be specified within the hostdev
(pick CCW or PCI as necessary):

    <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0625'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>

Add basic vhost-scsi tests which were cloned from hostdev-scsi-virtio-scsi
in both xml2argv and xml2xml. Added ones for both vhost-scsi-ccw and
vhost-scsi-pci since the syntaxes are slightly different between them.

Also adjusted the docs to describe the changes.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
      ae5d30a0
  45. 15 11月, 2016 3 次提交
    • L
      qemu: initially reserve one open pcie-root-port for hotplug · 70d15c9a
      由 Laine Stump 提交于 
      For machinetypes with a pci-root bus (all legacy PCI), libvirt will
make a "fake" reservation for one extra slot prior to assigning
addresses to unaddressed PCI endpoint devices in the domain. This will
trigger auto-adding of a pci-bridge for the final device to be
assigned an address *if that device would have otherwise instead been
the last device on the last available pci-bridge*; thus it assures
that there will always be at least one slot left open in the domain's
bus topology for expansion (which is important both for hotplug (since
a new pci-bridge can't be added while the guest is running) as well as
for offline additions to the config (since adding a new device might
otherwise in some cases require re-addressing existing devices, which
we want to avoid)).

It's important to note that for the above case (legacy PCI), we must
check for the special case of all slots on all buses being occupied
*prior to assigning any addresses*, and avoid attempting to reserve
the extra address in that case, because there is no free address in
the existing topology, so no place to auto-add a pci-bridge for
expansion (i.e. it would always fail anyway). Since that condition can
only be reached by manual intervention, this is acceptable.

For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's
methodology for automatically expanding the bus topology is different
- pcie-root-ports are plugged into slots (soon to be functions) of
pcie-root as needed, and the new endpoint devices are assigned to the
single slot in each pcie-root-port. This is done so that the devices
are, by default, hotpluggable (the slots of pcie-root don't support
hotplug, but the single slot of the pcie-root-port does). Since
pcie-root-ports can only be plugged into pcie-root, and we don't
auto-assign endpoint devices to the pcie-root slots, this means
topology expansion doesn't compete with endpoint devices for slots, so
we don't need to worry about checking for all "useful" slots being
free *prior* to assigning addresses to new endpoint devices - as a
matter of fact, if we attempt to reserve the open slots before the
used slots, it can lead to errors.

Instead this patch just reserves one slot for a "future potential"
PCIe device after doing the assignment for actual devices, but only
if the only PCI controller defined prior to starting address
assignment was pcie-root, and only if we auto-added at least one PCI
controller during address assignment. This assures two things:

1) that reserving the open slots will only be done when the domain is
   initially defined, never at any time after, and

2) that if the user understands enough about PCI controllers that they
   are adding them manually, that we don't mess up their plan by
   adding extras - if they know enough to add one pcie-root-port, or
   to manually assign addresses such that no pcie-root-ports are
   needed, they know enough to add extra pcie-root-ports if they want
   them (this could be called the "libguestfs clause", since
   libguestfs needs to be able to create domains with as few
   devices/controllers as possible).

This is set to reserve a single free port for now, but could be
increased in the future if public sentiment goes in that direction
(it's easy to increase later, but essentially impossible to decrease)
      70d15c9a
    • L
      qemu: try to put ich9 sound device at 00:1B.0 · 8d873a5a
      由 Laine Stump 提交于 
      Real Q35 hardware has an ICH9 chip that includes several integrated
devices at particular addresses (see the file docs/q35-chipset.cfg in
the qemu source). libvirt already attempts to put the first two sets
of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the
real hardware. This patch does the same for the ich9 "HD audio"
device.

The main inspiration for this patch is that currently the *only*
device in a reasonable "workstation" type virtual machine config that
requires a legacy PCI slot is the audio device, Without this patch,
the standard Q35 machine created by virt-manager will have a
dmi-to-pci-bridge and a pci-bridge just for the sound device; with the
patch (and if you change the sound device model from the default
"ich6" to "ich9"), the machine definition constructed by virt-manager
has absolutely no legacy PCI controllers - any legacy PCI devices
(e.g. video and sound) are on pcie-root as integrated devices.
      8d873a5a
    • L
      qemu: add a USB3 controller to Q35 domains by default · d8bd8376
      由 Laine Stump 提交于 
      Previously we added a set of EHCI+UHCI controllers to Q35 machines to
mimic real hardware as closely as possible, but recent discussions
have pointed out that the nec-usb-xhci (USB3) controller is much more
virtualization-friendly (uses less CPU), so this patch switches the
default for Q35 machinetypes to add an XHCI instead (if it's
supported, which it of course *will* be).

Since none of the existing test cases left out USB controllers in the
input XML, a new Q35 test case was added which has *no* devices, so
ends up with only the defaults always put in by qemu, plus those added
by libvirt.
      d8bd8376