- 15 7月, 2015 2 次提交
-
-
由 Boris Fiuczynski 提交于
For s390-ccw-virtio machines the default bus type is set to ccw. Specifing an address element allows to override the default. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NJason J. Herne <jjherne@us.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
-
由 Boris Fiuczynski 提交于
Adding the recently in qemu added 9pfs support for virtio-ccw. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NJason J. Herne <jjherne@us.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
-
- 08 7月, 2015 7 次提交
-
-
由 Luyao Huang 提交于
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. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Luyao Huang 提交于
As the backend of shmem server is a unix type chr device, save it in virDomainChrSourceDef, so we can reuse the existing code for chr device. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Luyao Huang 提交于
Rename qemuBuildShmemDevCmd to qemuBuildShmemDevStr and change the return type so that it can be reused in the device hotplug code later. And split the chardev creation part in a new function qemuBuildShmemBackendStr for reuse in the device hotplug code later. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Luyao Huang 提交于
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Luyao Huang 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1165029Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Ján Tomko 提交于
Since QEMU commit ea96bc6 [1]: i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wanted the floppy controller is no longer implicit. Specify it explicitly on the command line if the machine type version is 2.4 or later. Note that libvirt's floppy drives do not result in QEMU implying the controller, because libvirt uses if=none instead of if=floppy. https://bugzilla.redhat.com/show_bug.cgi?id=1227880 [1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ea96bc6
-
由 Ján Tomko 提交于
For the implicit controller, we set them via -global. Separating them will allow reuse for explicit fdc controller as well. No functional impact apart from one extra allocation.
-
- 01 7月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
Also check the device type when deciding what type the address should be. Commit 9807c471 (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. https://bugzilla.redhat.com/show_bug.cgi?id=1230039Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 30 6月, 2015 3 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1201760 When the domain "<on_crash>coredump-destroy</on_crash>" is set, the domain wasn't being destroyed, rather it was being rebooted. Add VIR_DOMAIN_LIFECYCLE_CRASH_COREDUMP_DESTROY to the list of on_crash types that cause "-no-reboot" to be added to the qemu command line.
-
由 John Ferlan 提交于
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
-
由 Jiri Denemark 提交于
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. https://bugzilla.redhat.com/show_bug.cgi?id=1179680Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 6月, 2015 2 次提交
-
-
由 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).
-
由 Laine Stump 提交于
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.
-
- 26 6月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
So far the argument has not much meaning and was practically ignored. This is not good since when doing memory hotplug, the size of desired hugepage backing is passed in that argument. Taking closer look at the tests I'm fixing reveals the bug. For instance, while the following is in the test: <memory model='dimm'> <source> <nodemask>1-3</nodemask> <pagesize unit='KiB'>4096</pagesize> </source> <target> <size unit='KiB'>524287</size> <node>0</node> </target> <address type='dimm' slot='0' base='0x100000000'/> </memory> the generated commandline corresponding to this XML was: -object memory-backend-ram,id=memdimm0,size=536870912,\ host-nodes=1-3,policy=bind Have you noticed? Yes, memory-backend-ram! Nothing can be further away from the right answer. The hugepage backing is requested in the XML and we happily ignore it. This is just not right. It's memory-backend-file which should have been used: -object memory-backend-file,id=memdimm0,prealloc=yes,\ mem-path=/dev/hugepages4M/libvirt/qemu,size=536870912,\ host-nodes=1-3,policy=bind The problem is, that @pagesize passed to qemuBuildMemoryBackendStr (where this part of commandline is built) was ignored. The hugepage to back memory was searched only and only by NUMA nodes pinning. This works only for regular guest NUMA nodes. Then, I'm changing the hugepages size in the test XMLs too. This is simply because in the test suite we create dummy mount points just for 2M and 1G hugepages. And in the test 4M was requested. I'm sticking to 2M, but 1G should just work too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1196644 This function constructs the backend (host facing) part of the memory device. At the beginning, the configured hugepages are searched to find the best match for given guest NUMA node. Configured hugepages can have a @nodeset attribute to specify on which guest NUMA nodes should be the hugepages backing used. There is, however, one 'corner case'. Users may just tell 'use hugepages to back all the nodes'. In other words: <memoryBacking> <hugepages/> </memoryBacking> <cpu> <numa> <cell id='0' cpus='0-1' memory='1024000' unit='KiB'/> </numa> </cpu> Our code fails in this case. Well, since there's no @nodeset (nor any <page/> child element to <hugepages/>) we fail to lookup the default hugepage size to use. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 6月, 2015 1 次提交
-
-
由 Boris Fiuczynski 提交于
This patch provides support for the new watchdog model "diag288". Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com> Reviewed-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>
-
- 18 6月, 2015 5 次提交
-
-
由 Peter Krempa 提交于
The privileged flag will not change while the configuration might change. Make the 'privileged' flag member of the driver again and mark it immutable. Should that ever change add an accessor that will group reads of the state.
-
由 James Cowgill 提交于
I needed to specify the iobase address for certain exotic mips configurations. Signed-off-by: NJames Cowgill <james410@cowgill.org.uk>
-
由 Luyao Huang 提交于
When hotplugging a memory device, there wasn't a check to determine if there is a conflict with the address space being used by the to be added memory device and any existing device which is disallowed by qemu. This patch adds a check to ensure the new device address doesn't conflict with any existing device. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Ján Tomko 提交于
If the address type is SPAPRVIO, it will match the != NONE condition.
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1220527 This type of information defines attributes of a system baseboard. With one exception: board type is yet not implemented in qemu so it's not introduced here either. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 6月, 2015 2 次提交
-
-
由 Ján Tomko 提交于
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1021480 Seems the property has been deprecated for qemu, although seemingly ignored. This patch enforces from a libvirt perspective that a scsi-block 'lun' device should not provide the 'serial' property.
-
- 12 6月, 2015 3 次提交
-
-
由 Michal Privoznik 提交于
We are using it to print a value that can't be NULL and does not need any escaping anyway. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Move all the system_* fields into a separate struct. Not only this simplifies the code a bit it also helps us to identify whether BIOS info is present. We don't have to check all the four variables for being not-NULL, but we can just check the pointer to the struct. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Move all the bios_* fields into a separate struct. Not only this simplifies the code a bit it also helps us to identify whether BIOS info is present. We don't have to check all the four variables for being not-NULL, but we can just check the pointer to the struct. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 6月, 2015 1 次提交
-
-
由 Maxime Leroy 提交于
This patch adds the support of queues attribute of the driver element for vhost-user interface type. Example: <interface type='vhostuser'> <mac address='52:54:00:ee:96:6d'/> <source type='unix' path='/tmp/vhost2.sock' mode='client'/> <model type='virtio'/> <driver queues='4'/> </interface> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1207692Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 09 6月, 2015 1 次提交
-
-
由 Cole Robinson 提交于
qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using qemu-system-aarch64 KVM to run armv7l VMs. Add a capabilities check for it, wire it up in qemu_command, and test the command line generation.
-
- 01 6月, 2015 2 次提交
-
-
由 Andrea Bolognani 提交于
The guest firmware provides the same functionality as the pvpanic device, which is not available in QEMU on pSeries, so the domain XML should be allowed to contain the <panic> element. On the other hand, unlike the pvpanic device, the guest firmware can't be configured, so report an error if an address has been provided in the XML. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1182388
-
由 Andrea Bolognani 提交于
-
- 29 5月, 2015 1 次提交
-
-
由 Ján Tomko 提交于
When attempting to hotplug a virtio-serial console to a domain that had no virtio-serial controllers (not even those that are added by libvirt when some devices need them) at daemon startup, report a user-friendly error: error: Failed to attach device from console.xml error: internal error: no virtio-serial controllers are available instead of crashing the daemon: Process terminating with default action of signal 11 (SIGSEGV): dumping core Access not within mapped region at address 0x8 at 0x531028F: virDomainVirtioSerialAddrNext (domain_addr.c:916) by 0x531028F: virDomainVirtioSerialAddrAssign (domain_addr.c:1029) by 0x1CBF68: qemuDomainAttachChrDevice (qemu_hotplug.c:1565) by 0x1BCD5E: qemuDomainAttachDeviceLive (qemu_driver.c:7997) by 0x1BCD5E: qemuDomainAttachDeviceFlags (qemu_driver.c:8743) Introduced in v1.2.14-30-g59033788.
-
- 26 5月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Recent changes to the -M/--machine processing code in qemuParseCommandLine caused Coverity to determine there was a possible resource leak with how the 'list' is managed. Rather than try to add virStringFreeList calls everywhere - just promote list to the top of the variables and free it within the error processing code. Also required a couple of other tweaks in order to avoid double free's.
-
- 21 5月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=998813 Implementation is pretty straight-forward. Of course, not all qemus out there supports the device, so new capability is introduced and checked prior each use of the device. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 5月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
So far, we are not reporting if numatune was even defined. The value of zero is blindly returned (which maps onto VIR_DOMAIN_NUMATUNE_MEM_STRICT). Unfortunately, we are making decisions based on this value. Instead, we should not only return the correct value, but report to the caller if the value is valid at all. For better viewing of this patch use '-w'. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 5月, 2015 1 次提交
-
-
由 Tony Krowiak 提交于
Introduces two new -machine option parameters to the QEMU command to enable/disable the CPACF protected key management operations for a guest: aes-key-wrap='on|off' dea-key-wrap='on|off' The QEMU code maps the corresponding domain configuration elements to the QEMU -machine option parameters to create the QEMU command: <cipher name='aes' state='on'> --> aes-key-wrap=on <cipher name='aes' state='off'> --> aes-key-wrap=off <cipher name='dea' state='on'> --> dea-key-wrap=on <cipher name='dea' state='off'> --> dea-key-wrap=off Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com> Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 5月, 2015 3 次提交
-
-
由 Laine Stump 提交于
We have previously effectively ignored all <controller type='ide'> elements in a domain definition. On the i440fx-based machinetypes there is an IDE controller that is included in the chipset and can't be removed (which is the ide controller with index='0'>), so it makes sense to ignore that one controller. However, if an i440fx domain definition has a 2nd controller, nothing catches this error (unless you also have a disk attached to it, in which case qemu will complain that you're trying to use the ide controller named "ide1", which doesn't exist), and if any other type of domain has even a single controller defined, it will be incorrectly ignored. Ignoring a bogus controller definition isn't such a big problem, as long as an error is logged when any disk is attached to that non-existent controller. But in the case of q35-based machinetypes, the hardcoded id ("alias" in libvirt terms) of its builtin SATA controller is "ide", which happens to be the same id as the builtin IDE controller on i440fx machinetypes. So libvirt creates a commandline believing that it is connecting the disk to the builtin (but actually nonexistent) IDE controller, qemu thinks that libvirt wanted that disk connected to the builtin SATA controller, and everybody is happy. Until you try to connect a 2nd disk to the IDE controller. Then qemu will complain that you're trying to set unit=1 on a controller that requires unit=0 (SATA controllers are organized differently than IDE controllers). After this patch, if a domain has an IDE controller defined for a machinetype that has no IDE controllers, libvirt will log an error about the controller itself as it is building the qemu commandline (rather than a (possible) error from qemu about disks attached to that controller). This is done by adding IDE to the list of controller types that are handled in the loop that creates controller command strings in qemuBuildCommandline() (previously it would *always* skip IDE controllers). Then qemuBuildControllerDevStr() is modified to log an appropriate error in the case of IDE controllers. In the future, if we add support for extra IDE controllers (piix3-ide and/or piix4-ide) we can just add it into the IDE case in qemuBuildControllerDevStr(). For now, nobody seems anxious to add extra support for an aging and very slow controller, when there are so many better options available. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1176071 (Fedora)
-
由 Laine Stump 提交于
Reorganize the loop that builds controller args to remove unnecessary duplicated code and superfluous else clauses. No functional change.
-
由 Laine Stump 提交于
This makes sure that that the commandlines generated for devices and controller devices are all using the alias that has been set in the controller's object as the id of the controller, rather than hardcoding a printf (or worse, encoding exceptions to the standard ${controller}${index} into the logic) Since this "fixes" the controller name used for the sata controller, the commandline arg for the sata controller in the sata test case had to be adjusted to be "sata0" instead of "ahci0". All other tests remain unchanged, verifying that the patch causes no other functional change. Because the function that finds a controller alias based on a device def requires a pointer to the full domainDef in order to get the list of controllers, the arglist of a few functions had to have this added.
-