- 10 8月, 2015 3 次提交
-
-
由 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.
-
由 Laine Stump 提交于
This patch provides qemu support for the contents of <model> in <controller> for the two existing PCI controller types that need it (i.e. the two controller types that are backed by a device that must be specified on the qemu commandline): 1) pci-bridge - sets <model> name attribute default as "pci-bridge" 2) dmi-to-pci-bridge - sets <model> name attribute default as "i82801b11-bridge". These both match current hardcoded practice. The defaults are set at the end of qemuDomainAssignPCIAddresses(). This can't be done earlier because some of the options that will be autogenerated need full PCI address info for the controller, and because qemuDomainAssignPCIAddresses() might create extra controllers which would need default settings added, and that hasn't yet been done at the time the PostParse callbacks are being run. qemuDomainAssignPCIAddresses() is still called prior to the XML being written to disk, though, so the autogenerated defaults are persistent. qemu capabilities bits aren't checked when the domain is defined, but rather when the commandline is actually created (so the domain can possibly be defined on a host that doesn't yet have support for the given device, or a host different from the one where it will eventually be run). When the commandline is being generated we compare the modelName to known qemu device names implementing the given type of controller, and check the capabilities bit for that device.
-
由 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)
-
- 09 8月, 2015 1 次提交
-
-
由 Laine Stump 提交于
If a pci address had a function number out of range, the error message would be: Insufficient specification for PCI address which is logged by virDevicePCIAddressParseXML() after virDevicePCIAddressIsValid returns a failure. This patch enhances virDevicePCIAddressIsValid() to optionally report the error itself (since it is the place that decides which part of the address is "invalid"), and uses that feature when calling from virDevicePCIAddressParseXML(), so that the error will be more useful, e.g.: Invalid PCI address function=0x8, must be <= 7 Previously, virDevicePCIAddressIsValid didn't check for the theoretical limits of domain or bus, only for slot or function. While adding log messages, we also correct that ommission. (The RNG for PCI addresses already enforces this limit, which by the way means that we can't add any negative tests for this - as far as I know our domainschematest has no provisions for passing XML that is supposed to fail). Note that virDevicePCIAddressIsValid() can only check against the absolute maximum attribute values for *any* possible PCI controller, not for the actual maximums of the specific controller that this device is attaching to; fortunately there is later more specific validation for guest-side PCI addresses when building the set of assigned PCI addresses. For host-side PCI addresses (e.g. for <hostdev> and for network device pools), we rely on the error that will be logged when it is found that the device doesn't actually exist. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004596
-
- 07 8月, 2015 3 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1176020 Some users think this is a good idea: <vcpu placement='static'>4</vcpu> <cpu mode='host-model'> <model fallback='allow'/> <numa> <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/> <cell id='1' cpus='9-10' memory='2097152' unit='KiB'/> </numa> </cpu> It's not. Lets therefore introduce a check and discourage them in doing so. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This function should return the greatest CPU number set in /domain/cpu/numa/cell/@cpus. The idea is that we should compare the returned value against /domain/vcpu value. Yes, there exist users who think the following is a good idea: <vcpu placement='static'>4</vcpu> <cpu mode='host-model'> <model fallback='allow'/> <numa> <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/> <cell id='1' cpus='9-10' memory='2097152' unit='KiB'/> </numa> </cpu> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Qemu reports physical size 0 for block devices. As 15fa84ac changed the behavior of qemuDomainGetBlockInfo to just query the monitor this created a regression since we didn't report the size correctly any more. This patch adds code to refresh the physical size of a block device by opening it and seeking to the end and uses it both in qemuDomainGetBlockInfo and also in qemuDomainGetStatsOneBlock that was broken since it was introduced in this respect. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250982
-
- 06 8月, 2015 6 次提交
-
-
由 Shivaprasad G Bhat 提交于
The commit 7e72de49 didn't consider the hotplug scenarios. The patch addresses the hotplug case whereby if atleast one of the pci function is owned by a guest, the hotplug of other functions/devices in the same iommu group to the same guest goes through successfully. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
-
由 Michal Privoznik 提交于
While reviewing e8d55172 I've noticed a few unaligned lines. Fix this. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Pavel Fedin 提交于
virtio-net-pci adapter is capable to use irqfd with vhost-net only in MSI-X mode, which appears to be available only on PCIe bus, at least on ARM Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
-
由 Pavel Fedin 提交于
Legacy -net option works correctly only with embedded device models, which do not require any bus specification. Therefore, we should use -device for PCI hardware Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
-
由 Pavel Fedin 提交于
Here we assume that if qemu supports generic PCI host controller, it is a part of virt machine and can be used for adding PCI devices. In qemu this is actually a PCIe bus, so we also declare multibus capability so that 0'th bus is specified to qemu correctly as 'pcie.0' Signed-off-by: NPavel Fedin <p.fedin@samsung.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Pavel Fedin 提交于
This capability specifies that qemu can implement generic PCI host controller. It is often used for virtual environments, including ARM. Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
-
- 05 8月, 2015 6 次提交
-
-
由 Peter Krempa 提交于
Libvirt doesn't reliably know the location of the backing chain when pre-creating images for non-shared migration. This isn't a problem for full copy, but incremental copy requires the information. Forbid pre-creating the image in cases where incremental migration is required. This limitation can perhaps be lifted once libvirt will fully support loading of backing chain information from the XML. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1249587
-
由 Andrea Bolognani 提交于
-
由 Andrea Bolognani 提交于
Update the names of the symbols used internally by the driver. No functional changes.
-
由 Andrea Bolognani 提交于
Only the symbols exported by the driver have been updated; the driver implementation itself still uses the old names internally. No functional changes.
-
由 Andrea Bolognani 提交于
The driver only supports VIR_ARCH_PPC64 and VIR_ARCH_PPC64LE. Just shuffling files around and updating the build system accordingly. No functional changes.
-
由 John Ferlan 提交于
The recent changes to perform SCSI device address checks during the post parse callbacks ran afoul of the Coverity checker since the changes assumed that the 'xmlopt' parameter to virDomainDeviceDefPostParse would be non NULL (commit id 'ca2cf74e'); however, what was missed is there was an "if (xmlopt &&" check being made, so Coverity believed that it could be possible for a NULL 'xmlopt'. Checking the various calling paths seemingly disproves that. If called from virDomainDeviceDefParse, there were two other possible calls that would end up dereffing, so that path could not be NULL. If called via virDomainDefPostParseDeviceIterator via virDomainDefPostParse there are two callers (virDomainDefParseXML and qemuParseCommandLine) which deref xmlopt either directly or through another call. So I'm removing the check for non-NULL xmlopt.
-
- 04 8月, 2015 12 次提交
-
-
由 John Ferlan 提交于
Rather than provide a somewhat generic error message when the API returns false, allow the caller to supply a "report = true" option in order to cause virReportError's to describe which of the 3 paths that can cause failure. Some callers don't care about what caused the failure, they just want to have a true/false - for those, calling with report = false should be sufficient.
-
由 Kothapally Madhu Pavan 提交于
PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from creating qemu command with floppy device. Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com> https://bugzilla.redhat.com/show_bug.cgi?id=1180486Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Kothapally Madhu Pavan 提交于
PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from adding floppy disk for a PowerPC pseries VM. Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
-
由 John Ferlan 提交于
Rather than calling virDomainDiskDefAssignAddress during the parsing of the XML, moving the setting of disk addresses into the domain/device post processing. Commit id '37588b25' which introduced VIR_DOMAIN_DEF_PARSE_DISK_SOURCE in order to avoid generating the address which wasn't required will not be affected by this as all it cared about was processing the source XML. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Remove unused xmlopt param Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than calling virDomainHostdevAssignAddress during the parsing of the XML, move the setting of a default hostdev address to domain/ device post processing. Since the parse code no longer generates an address, we can remove the virDomainDefMaybeAddHostdevSCSIcontroller since the call to virDomainHostdevAssignAddress will attempt to add the controllers that were not already defined in the XML. This patch will also enforce that the address type is type 'drive' when a SCSI subsystem <hostdev> element is provided with an <address>. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
If virDomainControllerSCSINextUnit failed to find a slot on the current VIR_DOMAIN_CONTROLLER_TYPE_SCSI controller(s), try to add a new controller; otherwise, there may be multiple unit=0 entries for the same "next" controller. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
While searching the hostdevs the drive type can be either *_TYPE_DRIVE or *_TYPE_NONE. If the type is _TYPE_NONE on the first scsi_host, then there is an erroneous "match" that the address already exists. Although this works by chance currently because hostdev's are added one at a time and 'nhostdevs' would be zero, thus returning false for the first hostdev added, a future patch will move the hostdev address assignment into post processing resulting in the bad match. This code is only called by path's expecting either drive or none. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add the xmlopt parameter that was saved during virDomainDefPostParse to the parameters. A future patch will use it. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move the functions above the post processing for upcoming patch Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Modify virDomainDriveAddressIsUsedBy{Disk|Hostdev} and virDomainSCSIDriveAddressIsUsed to take 'bus' and 'target' parameters. Will be used by future patches for more complete address conflict checks Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since the only way virDomainHostdevAssignAddress can be called is from within virDomainHostdevDefParseXML when hostdev->source.subsys.type is VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI, thus there's no need for redundancy. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 03 8月, 2015 6 次提交
-
-
由 Andrea Bolognani 提交于
Compiler error: ../../src/nodeinfo.c: In function 'nodeGetThreadsPerSubcore': ../../src/nodeinfo.c:2393: error: label 'out' defined but not used [-Wunused-label] ../../src/nodeinfo.c:2352: error: unused parameter 'arch' [-Wunused-parameter]
-
由 Martin Kletzander 提交于
The virDomainObjListRemove() function unlocks a domain that it's given due to legacy code. And because of that code, which should be refactored, that last virObjectUnlock() cannot be just removed. So instead, lock it right back for qemu for now. All calls to qemuDomainRemoveInactive() are followed by code that unlocks the domain again, plus the domain should be locked during qemuDomainObjEndJob(), so the right place to lock it is right after virDomainObjListRemove(). The only place where this would cause a problem is the autodestroy callback, so we need to get another reference there and uref+unlock it afterwards. Luckily, returning NULL from that function doesn't mean an error, and only means that it doesn't need to be unlocked anymore. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Shivaprasad G Bhat 提交于
The nodeinfo is reporting incorrect number of cpus and incorrect host topology on PPC64 KVM hosts. The KVM hypervisor on PPC64 needs only the primary thread in a core to be online, and the secondaries offlined. While scheduling a guest in, the kvm scheduler wakes up the secondaries to run in guest context. The host scheduling of the guests happen at the core level(as only primary thread is online). The kvm scheduler exploits as many threads of the core as needed by guest. Further, starting POWER8, the processor allows splitting a physical core into multiple subcores with 2 or 4 threads each. Again, only the primary thread in a subcore is online in the host. The KVM-PPC scheduler allows guests to exploit all the offline threads in the subcore, by bringing them online when needed. (Kernel patches on split-core http://www.spinics.net/lists/kvm-ppc/msg09121.html) Recently with dynamic micro-threading changes in ppc-kvm, makes sure to utilize all the offline cpus across guests, and across guests with different cpu topologies. (https://www.mail-archive.com/kvm@vger.kernel.org/msg115978.html) Since the offline cpus are brought online in the guest context, it is safe to count them as online. Nodeinfo today discounts these offline cpus from cpu count/topology calclulation, and the nodeinfo output is not of any help and the host appears overcommited when it is actually not. The patch carefully counts those offline threads whose primary threads are online. The host topology displayed by the nodeinfo is also fixed when the host is in valid kvm state. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ossi Herrala 提交于
Use I/O vector (iovec) instead of one huge memory buffer as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1026137#c7. This avoids doing memmove() to big buffers and performance doesn't degrade if source (virNetClientStreamQueuePacket()) is faster than sink (virNetClientStreamRecvPacket()). Resolves: http://bugzilla.redhat.com/1026137Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Cao jin 提交于
s/virDomainFindBy/virDomainObjListFindBy/ Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
-
由 Luyao Huang 提交于
If cpuset is disabled or not available, it libvirt must not use it. Mainly for actions that do not need it and can use sched_setaffinity() or numa_membind() instead, because they will fail without good reason. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1244664Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 31 7月, 2015 2 次提交
-
-
由 Jiri Denemark 提交于
When stopping a domain on the destination host after a failed migration, we need to avoid reseting security labels since the domain is still running on the source host. While we were correctly doing so in some cases, there were still some paths which did this wrong. https://bugzilla.redhat.com/show_bug.cgi?id=1242904Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
In addition to checking the current asynchronous job qemuMigrationJobIsActive reports an error if the current job does not match the one we asked for. Let's just check the job directly since we are not interested in the error in qemuProcessHandleMonitorEOF. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 30 7月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
If destination libvirt doesn't support memory hotplug since all the support was introduced by adding new elements the destination would attempt to start qemu with an invalid configuration. The worse part is that qemu might hang in such situation. Fix this by sending a required migration feature called 'memory-hotplug' to the destination. If the destination doesn't recognize it it will fail the migration. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1248350
-