Jim Fehlig [Mon, 22 Jun 2015 17:36:59 +0000 (11:36 -0600)]
libxl: support dom0
In Xen, dom0 is really just another domain that supports ballooning,
adding/removing devices, changing vcpu configuration, etc. This patch
adds support to the libxl driver for managing dom0. Note that the
legacy xend driver has long supported managing dom0.
Operations that are not supported on dom0 are filtered in libvirt
where a sensible error is reported. Errors from libxl are not
always helpful. E.g., attempting a save on dom0 results in
2015-06-23 15:25:05 MDT libxl: debug: libxl_dom.c:1570:libxl__toolstack_save: domain=0 toolstack data size=8
2015-06-23 15:25:05 MDT libxl: debug: libxl.c:979:do_libxl_domain_suspend: ao 0x7f7e68000b70: inprogress: poller=0x7f7e68000930, flags=i
2015-06-23 15:25:05 MDT libxl-save-helper: debug: starting save: Success
2015-06-23 15:25:05 MDT xc: detail: xc_domain_save_suse: starting save of domid 0
2015-06-23 15:25:05 MDT xc: error: Couldn't map live_shinfo (3 = No such process): Internal error
2015-06-23 15:25:05 MDT xc: detail: Save exit of domid 0 with errno=3
2015-06-23 15:25:05 MDT libxl-save-helper: debug: complete r=1: No such process
2015-06-23 15:25:05 MDT libxl: error: libxl_dom.c:1876:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: No such process
2015-06-23 15:25:05 MDT libxl: error: libxl_dom.c:2033:remus_teardown_done: Remus: failed to teardown device for guest with domid 0, rc -8
John Ferlan [Tue, 16 Jun 2015 17:33:37 +0000 (13:33 -0400)]
qemu: Introduce qemuIsSharedHostdev
Add a single boolean function to handle whether the hostdev is shared or not.
Use the new function for the qemu{Add|Remove}SharedHostdev calls as well
as qemuSetUnprivSGIO. NB: This third usage fixes a possible bug where
if this feature is enabled at some time in the future and the shareable flag
wasn't set, the sgio would have been erroneously set.
Luyao Huang [Wed, 17 Jun 2015 03:56:21 +0000 (11:56 +0800)]
qemu: report error when shmem has an invalid address
If user passes an invalid address for shared memory device to qemu,
neither libvirt nor qemu will report an error, but qemu will auto assign
a pci address to the shared memory device.
It is better not to assume that newly created network should be
connected to a bridge with same name, but specify it explicitly
by PRL_USE_VNET_NAME_FOR_BRIDGE_NAME flag.
Erik Skultety [Thu, 2 Jul 2015 12:41:37 +0000 (14:41 +0200)]
storage: Fix regression in storagePoolUpdateAllState
Commit 2a31c5f0 introduced support for storage pool state XMLs, however
it also introduced a regression:
if (!virstoragePoolObjIsActive(pool)) {
virStoragePoolObjUnlock(pool);
continue;
}
The idea behind this was that since we've got state XMLs and the pool
wasn't marked as active by autostart routine (if the autostart flag had been
set earlier), the pool is inactive and we can leave it be and continue with
other pools. However, filesystem type pools like fs,dir, possibly netfs are
supposed to be active if the filesystem is mounted on the host. And this is
exactly where the regression occurs, e.g. pool type 'dir' which has been
previously destroyed and marked as !autostart gets filtered out
by the condition above.
The resolution should be simply to remove the condition completely,
all pools will get their 'active' flag updated by check callback and if
they do not support such callback, the logic doesn't change and such
pools will be inactive by default (e.g. RBD, even if a state XML exists).
Peter Krempa [Thu, 2 Jul 2015 14:46:46 +0000 (16:46 +0200)]
util: bitmap: Don't alloc overly large binary bitmaps
Optimize the virBitmap to array-of-char bitmap conversion by skipping
trailing zero bytes.
This also fixes a regression when requesting iothread information from a
live VM since after commit 825df8c3158cfaf5f398418471f10f4ff3c3515a the
bitmap returned from virProcessGetAffinity is too big to be formatted
properly via RPC. A user would get the following error:
error: Unable to get domain IOThreads information
error: Unable to encode message payload
qemu: move the guest status check before agent config and status check
When use setvcpus command with --guest option to a offline vm,
we will get error:
# virsh setvcpus test3 1 --guest
error: Guest agent is not responding: QEMU guest agent is not connected
However guest is not running, agent status could not be connected.
In this case, report domain is not running will be better than agent is
not connected. Move the guest status check more early to output error to
point out guest status is not right.
Also from the logic, a running vm is a basic requirement to use
agent, we cannot use agent if vm is not running.
Signed-off-by: Luyao Huang <lhuang@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
vz: assign static IPs and default gateways for network adapter
We support only one IPv4 and one IPv6 default gateway.
If static IPs are not present in instance config,
then we switch on DHCP for this adapter.
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.
Current version of SDK event dispatcing is incorrect. For most VM events (add,
delete etc) issuer type is PIE_DISPATCHER. Actually analyzing issuer type
doesn't have any benifints so this patch get rid of it. All dispatching is done
only on event type.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
John Ferlan [Wed, 1 Jul 2015 13:35:43 +0000 (09:35 -0400)]
util: Avoid Coverity FORWARD_NULL
Avoid a false positive since Coverity find a path in virResizeN which
could return 0 prior to the allocation of memory and thus flags a
possible NULL dereference. Instead allocate the output buffer based
on 'nparams' and only fill it partially if need be - shouldn't be too
much a waste of space. Quicker than multiple VIR_RESIZE_N calls or
two loops of STREQ's sandwiched around a single VIR_ALLOC_N using
'n' matches from a first loop to generate the 'n' addresses to return
Luyao Huang [Mon, 29 Jun 2015 02:10:15 +0000 (10:10 +0800)]
virsh: report error if vcpu number exceed the guest maxvcpu number
Commit id '81dd81e' caused a regression when attempting to print a
specific vcpuid that is out of the range of the maximum vcpus for
the guest, such as:
$ virsh vcpupin $dom 1000
VCPU: CPU Affinity
----------------------------------
$
Rather than just recover the old message, let's adjust the message based
on what would be displayed for a similar failure in the set path, such as:
$ virsh vcpupin $dom 1000
error: vcpu 1000 is out of range of persistent cpu count 2
$ virsh vcpupin $dom 1000 --live
error: vcpu 1000 is out of range of live cpu count 2
Michal Dubiel [Wed, 1 Jul 2015 08:15:29 +0000 (10:15 +0200)]
virt-aa-helper: Fix permissions for vhost-user socket files
QEMU working in vhost-user mode communicates with the other end (i.e.
some virtual router application) via unix domain sockets. This requires
that permissions for the socket files are correctly written into
/etc/apparmor.d/libvirt/libvirt-UUID.files.
Jiri Denemark [Tue, 23 Jun 2015 13:14:22 +0000 (15:14 +0200)]
cpu_map.xml: Expand Opteron_G4 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:12:27 +0000 (15:12 +0200)]
cpu_map.xml: Expand Opteron_G2 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:11:53 +0000 (15:11 +0200)]
cpu_map.xml: Expand Opteron_G1 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:10:28 +0000 (15:10 +0200)]
cpu_map.xml: Expand Broadwell-noTSX CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:10:28 +0000 (15:10 +0200)]
cpu_map.xml: Expand Haswell-noTSX CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:08:40 +0000 (15:08 +0200)]
cpu_map.xml: Expand SandyBridge CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:06:32 +0000 (15:06 +0200)]
cpu_map.xml: Expand Westmere CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:05:47 +0000 (15:05 +0200)]
cpu_map.xml: Expand Nehalem CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:04:24 +0000 (15:04 +0200)]
cpu_map.xml: Expand Penryn CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:03:07 +0000 (15:03 +0200)]
cpu_map.xml: Expand Conroe CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:47:08 +0000 (14:47 +0200)]
cpu_map.xml: Expand kvm64 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:45:51 +0000 (14:45 +0200)]
cpu_map.xml: Expand cpu64-rhel5 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:43:52 +0000 (14:43 +0200)]
cpu_map.xml: Expand kvm32 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:42:43 +0000 (14:42 +0200)]
cpu_map.xml: Expand qemu32 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:40:28 +0000 (14:40 +0200)]
cpu_map.xml: Expand n270 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:39:27 +0000 (14:39 +0200)]
cpu_map.xml: Expand coreduo CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:38:06 +0000 (14:38 +0200)]
cpu_map.xml: Expand pentiumpro CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:36:15 +0000 (14:36 +0200)]
cpu_map.xml: Expand pentium2 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:34:41 +0000 (14:34 +0200)]
cpu_map.xml: Expand pentium CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:33:39 +0000 (14:33 +0200)]
cpu_map.xml: Expand 486 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
John Ferlan [Wed, 1 Jul 2015 10:32:34 +0000 (06:32 -0400)]
phyp: Resolve Coverity FORWARD_NULL
Commit id 'cd490086' added a VIR_FORCE_CLOSE of the 'sock', but it
was after the VIR_FREE() of phyp_driver, resulting in a possible/likely
NULL dereference.
So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:
virsh # start --console test
error: Reconnected to the hypervisor
error: Failed to start domain test
error: internal error: guest failed to start: unexpected exit status 125
So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:
Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.
In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.
Peter Krempa [Fri, 26 Jun 2015 08:59:33 +0000 (10:59 +0200)]
conf: qemu: Taint VMs using custom device tree blob
Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.
we would generate "/var/lib/libvirt/qemu/channel/target/NAME.(null)"
path which works but is not really correct. Let's not use the
".target_name" suffix at all if target name is not set.
Peter Krempa [Fri, 26 Jun 2015 11:58:20 +0000 (13:58 +0200)]
qemu: agent: Don't automatically disable CPU0 via guest agent
While CPU0 was made unpluggable in Linux a while ago it's not desirable
to unplug it since some parts of the kernel (suspend-to-ram) still
depend on it.
This patch fixes the vCPU selection code in libvirt so that it will not
be disabled.
Ján Tomko [Tue, 30 Jun 2015 13:48:20 +0000 (15:48 +0200)]
qemu: properly free addresses on non-serial chardev unplug
The target type comparison in qemuDomainDetachChrDevice
used the VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE enum, so virtio-serial
addresses were not freed properly for channel devices.
Call qemuDomainReleaseDeviceAddress uncoditionally and decide
based on the address type instead of the target/device types.
Luyao Huang [Wed, 10 Jun 2015 14:49:37 +0000 (22:49 +0800)]
qemu: fix address allocation on chardev attach
Also check the device type when deciding what type the address should
be. Commit 9807c47 (aiming to fix another error in address allocation)
only checked the target type, but its value is different for different
device types. This resulted in an error when trying to attach
a channel with target type 'virtio':
error: Failed to attach device from channel-file.xml
error: internal error: virtio serial device has invalid address type
Make the logic for releasing the address dependent only on
* the address type
* whether it was allocated earlier
to avoid copying the device and target type checks.
Jim Fehlig [Mon, 29 Jun 2015 16:46:36 +0000 (10:46 -0600)]
libxl: Set def->vcpus after successfully modifying live vcpu count
def->vcpus was never updated after successfully changing the live
vcpu count of a domain. Subsequent queries for vcpu info would
return incorrect results. E.g.:
virsh vcpucount test
maximum config 4
maximum live 4
current config 4
current live 4
virsh setvcpus test 2
virsh vcpucount test
maximum config 4
maximum live 4
current config 4
current live 4
After patch, live current config is reported correctly:
virsh vcpucount test
maximum config 4
maximum live 4
current config 4
current live 2
While fixing this, noticed that the live config was not saved
to cfg->stateDir via virDomainSaveStatus. Save the live config
and change error handling of virDomainSave{Config,Status} to
log a message via VIR_WARN, instead of failing the entire
DomainSetVcpusFlags operation.
Jim Fehlig [Wed, 24 Jun 2015 21:02:15 +0000 (15:02 -0600)]
libxl: don't overwrite domain state from statedir config
When restarting libvirtd and reconnecting to running domains,
libxlReconnectDomain() would unconditionally set the domain state
to VIR_DOMAIN_RUNNING, overwriting the state maintained in
$statedir/<domname>.xml. A domain in a paused state would have
the state changed to running, even though it was actually in a
paused state.
John Ferlan [Mon, 29 Jun 2015 19:22:28 +0000 (15:22 -0400)]
Use the correct symbol for 'onCrash'
Although defined the same way, fortunately there hadn't been any deviation.
Ensure any assignments to onCrash use VIR_DOMAIN_LIFECYCLE_CRASH_* defs and
not VIR_DOMAIN_LIFECYCLE_* defs
Since an mpath pool contains all the Multipath devices on a host, allowing
more than one defined on a host at a time should be disallowed under the
policy of disallowing duplicate source pools for the host.
Adjust to docs to clarify the Multipath target path value usage for both
the storage driver (only 1 pool per host) and formatstorage references
(ignore the target element in favor of the default target mapping of
/dev/mapper).
Per the devmapper docs, use "/dev/mapper" or "/dev/dm-n" in order to
determine if a device is under control of DM Multipath.
So add "/dev/mapper" to the virFileExists, leaving the "/dev/mpath"
as a "legacy" option since it appears for a while it was the preferred
mechanism, but is no longer maintained
The formatdomain.html description for <disk> device 'lun' indicates that
it must be either a type 'block' or type 'network' with protocol 'iscsi';
however, we did not make that check until domain startup.
This caused issues for virt-manager which had an unexpected failure at
run time rather config time.
This patch adds a check in post part disk device checking for the specific
and supported lun types as well as adjusting the test failure to be for
parse config rather than run time.
Prerna Saxena [Fri, 26 Jun 2015 11:35:11 +0000 (17:05 +0530)]
Storage: Introduce shadow vol for refresh while the main vol builds.
Libvirt periodically refreshes all volumes in a storage pool, including
the volumes being cloned.
While cloning a storage volume from parent, we drop pool locks. Subsequent
volume refresh sometimes changes allocation for an ongoing copy, and leads
to corrupt images.
Fix: Introduce a shadow volume that isolates the volume object under refresh
from the base which has a copy ongoing.
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 30 Jun 2015 08:14:17 +0000 (10:14 +0200)]
conf: storage: Fix duplicate check for gluster pools
The pool name has to be the same too to warrant rejecting a pool
definition as duplicate. This regression was introduced in commit 2184ade3a0546b915252cb3b6a5dc88e9a8d2ccf.
Peter Krempa [Mon, 29 Jun 2015 14:10:51 +0000 (16:10 +0200)]
qemu: event: Properly handle spice events
Spice events have mostly similar information present in the event JSON
but they differ in the name of the element containing the port.
The JSON event also provides connection ID which might be useful in the
future.
This patch splits up the event parser code into two functions and the
SPICE reimplements the event parsing with correct names and drops the
VNC only stuff.
Peter Krempa [Tue, 30 Jun 2015 08:46:50 +0000 (10:46 +0200)]
qemu: Close the agent connection only on agent channel events
processSerialChangedEvent processes events for all channels. Commit 2af51483 broke all agent interaction if a channel other than the agent
closes since it did not check that the event actually originated from
the guest agent channel.
If the requested format type for the new entry in the file system pool
is a 'dir', then be sure to set the vol->type correctly as would be done
when the pool is refreshed.
Jiri Denemark [Tue, 30 Jun 2015 08:21:21 +0000 (10:21 +0200)]
qemu: Fix assignment of the default spicevmc channel name
Make sure we only assign the default spicevmc channel name to spicevmc
virtio channels. Caused by commits 3269ee65 and 1133ee2b, which moved
the assignment from XML parsing code to QEMU but failed to keep the
logic.
Jiri Denemark [Mon, 29 Jun 2015 11:19:21 +0000 (13:19 +0200)]
qemuxml2argv: Remove Haswell CPU from unrelated tests
Proper Haswell CPU model handling is tested in several
qemuxml2argv-cpu-* which are run in a special environment. Let's remove
the CPU model from other tests to make them less fragile.
Its only file must be included in the daemon package anyway, since the
daemon is linked with the admin library and so then it's just an empty
package until we have virt-admin binary which we can decide later on
whether to just move it to clients or create a new package for it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
John Ferlan [Fri, 26 Jun 2015 18:09:59 +0000 (14:09 -0400)]
docs: Clarification for when allowed to use 'lun' for "volume"
While re-reading what I wrote for commit id '785a8940e', 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.
Laine Stump [Fri, 12 Jun 2015 18:54:23 +0000 (14:54 -0400)]
docs: document when pcie-root/dmi-to-pci-bridge support was added
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.
Laine Stump [Wed, 10 Jun 2015 18:15:25 +0000 (14:15 -0400)]
qemu: ignore assumptions about hotplug requirement when address is from config
Certain PCI buses don't support hotplug, and when automatically
assigning PCI addresses for devices, libvirt is very conservative in
its assumptions about whether or not a device will need to be
hotplugged/unplugged in the future. But if the user manually assigns
an address, they likely are aware of any hotplug requirements of the
device (or at least they should be).
In short, after this patch, automatically PCI address assignment will
assume that the device must be plugged in to a hot-pluggable slot, but
manually assignment can place the device in any bus that is
compatible, regardless of whether or not it supports hotplug. If the
user makes a mistake and plugs the device into a bus that doesn't
support hotplug, then later tries to do a hot-unplug, qemu will give
an appropriate error.
(in the future we may want to add a "hotpluggable" attribute to all
devices, with default being "yes" for autoassign, and "no" for manual
assign).
Laine Stump [Tue, 9 Jun 2015 17:33:36 +0000 (13:33 -0400)]
qemu: always permit PCI devices to be manually assigned to a PCIe bus
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).
Laine Stump [Tue, 16 Jun 2015 19:22:57 +0000 (15:22 -0400)]
qemu: refactor qemuBuildControllerDevStr to eliminate future duplicate code
The PCI case of the switch statement in this function contains another
switch statement with a case for each model. Currently every model
except pci-root and pcie-root has a check for index > 0 (since only
those two can have index==0), and the function should never be called
for those two anyway. If we move the check for !pci[e]-root to the top
of the pci case, then we can move the check for index > 0 out of the
individual model cases. This will save repeating that check for the
three new controller models about to be added.
projects / libvirt.git / log