- 01 7月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
-
- 21 6月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
XML: <features> <hyperv> <vapic state='on'/> <spinlocks state='on' retries='4096'/> </hyperv> </features> results in the following QEMU command line: qemu -cpu <cpu_model>,hv_vapic,hv_spinlocks=0x1000 https://bugzilla.redhat.com/show_bug.cgi?id=784836
-
由 Ján Tomko 提交于
Add new CPU features for HyperV: vapic for virtual APIC support spinlocks for setting spinlock support <features> <hyperv> <vapic state='on'/> <spinlocks state='on' retries='4096'/> </hyperv> </features> https://bugzilla.redhat.com/show_bug.cgi?id=784836
-
- 07 6月, 2013 1 次提交
-
-
由 Osier Yang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964177 Though both libvirt and QEMU's document say RTC_CHANGE returns the offset from the host UTC, qemu actually returns the offset from the specified date instead when specific date is provided (-rtc base=$date). It's not safe for qemu to fix it in code, it worked like that for 3 years, changing it now may break other QEMU use cases. What qemu tries to do is to fix the document: http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg04782.html And in libvirt side, instead of replying on the value from qemu, this converts the offset returned from qemu to the offset from host UTC, by: /* * a: the offset from qemu RTC_CHANGE event * b: The specified date (-rtc base=$date) * c: the host date when libvirt gets the RTC_CHANGE event * offset: What libvirt will report */ offset = a + (b - c); The specified date (-rtc base=$date) is recorded in clock's def as an internal only member (may be useful to exposed outside?). Internal only XML tag "basetime" is introduced to not lose the guest's basetime after libvirt restarting/reloading: <clock offset='variable' adjustment='304' basis='utc' basetime='1370423588'/>
-
- 06 6月, 2013 2 次提交
- 29 5月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Currently, if there's an error opening /dev/vhost-net (e.g. because it doesn't exist) but it's not required we proceed with vhostfd array filled with -1 and vhostfdSize unchanged. Later, when constructing the qemu command line only non-negative items within vhostfd array are taken into account. This means, vhostfdSize may be greater than the actual count of non-negative items in vhostfd array. This results in improper command line arguments being generated, e.g.: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=(null)
-
- 24 5月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
With previous patch, we accept negative value as length of string to duplicate. So there is no need to pass strlen(src) in case we want to do duplicate the whole string.
-
- 23 5月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
-
- 22 5月, 2013 4 次提交
-
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
In order to learn libvirt multiqueue several things must be done: 1) The '/dev/net/tun' device needs to be opened multiple times with IFF_MULTI_QUEUE flag passed to ioctl(fd, TUNSETIFF, &ifr); 2) Similarly, '/dev/vhost-net' must be opened as many times as in 1) in order to keep 1:1 ratio recommended by qemu and kernel folks. 3) The command line construction code needs to switch from 'fd=X' to 'fds=X:Y:...:Z' and from 'vhostfd=X' to 'vhostfds=X:Y:...:Z'. 4) The monitor handling code needs to learn to pass multiple FDs.
-
由 Michal Privoznik 提交于
Currently, we have one huge function to construct qemu command line. This is very ineffective esp. if there's a fault somewhere.
-
由 Guannan Ren 提交于
example: qemu ${otherargs} \ -vnc 127.0.0.1:0,share=allow-exclusive
-
- 21 5月, 2013 1 次提交
-
-
由 Osier Yang 提交于
-
- 20 5月, 2013 1 次提交
-
-
由 Osier Yang 提交于
Since 0d70656a, it starts to access the sysfs files to build the qemu command line (by virSCSIDeviceGetSgName, which is to find out the scsi generic device name by adpater:bus:target:unit), there is no way to work around, qemu wants to see the scsi generic device like "/dev/sg6" anyway. And there might be other places which need to access sysfs files when building qemu command line in future. Instead of increasing the arguments of qemuBuildCommandLine, this introduces a new callback for qemuBuildCommandLine, and thus tests can register their own callbacks for sysfs test input files accessing. * src/qemu/qemu_command.h: (New callback struct qemuBuildCommandLineCallbacks; extern buildCommandLineCallbacks) * src/qemu/qemu_command.c: (wire up the callback struct) * src/qemu/qemu_driver.c: (Use the new syntax of qemuBuildCommandLine) * src/qemu/qemu_hotplug.c: Likewise * src/qemu/qemu_process.c: Likewise * tests/testutilsqemu.[ch]: (Helper testSCSIDeviceGetSgName; callback struct testCallbacks;) * tests/qemuxml2argvtest.c: (Use testCallbacks) * src/tests/qemuxmlnstest.c: (Like above)
-
- 17 5月, 2013 1 次提交
-
-
由 Jiri Denemark 提交于
-
- 15 5月, 2013 4 次提交
-
-
由 Osier Yang 提交于
QEMU introduced "discard" option for drive since commit a9384aff53, <...> @var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap}) requests are ignored or passed to the filesystem. Some machine types may not support discard requests. </...> This patch exposes the support in libvirt. QEMU supported "discard" for "-drive" since v1.5.0-rc0: % git tag --contains a9384aff53 contains v1.5.0-rc0 v1.5.0-rc1 So this only detects the capability bit using virQEMUCapsProbeQMPCommandLine.
-
由 John Ferlan 提交于
During building of the qemu command line determine whether to add/use the '-no-reboot' option only if each of the 'on' events want to to destroy the domain; otherwise, use the '-no-shutdown' option. Prior to this change both could be on the command line, which while allowed could be construed as a conflict.
-
由 Martin Kletzander 提交于
Adding a VNC WebSocket support for QEMU driver. This functionality is in upstream qemu from commit described as v1.3.0-982-g7536ee4, so the capability is being recognized based on QEMU version for now.
-
由 Osier Yang 提交于
QEMU introduced command line "-mem-merge=on|off" (defaults to on) to enable/disable the memory merge (KSM) at guest startup. This exposes it by new XML: <memoryBacking> <nosharepages/> </memoryBacking> The XML tag is same with what we used internally for old RHEL.
-
- 14 5月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The QEMU command line syntax for RBD disks is file=rbd:pool/image:opt1=val1:opt2=val2... There is no way to escape the ':' if it appears in the pool or image name. Thus it must be explicitly forbidden if it occurs in the libvirt XML. People are known to be abusing the lack of escaping in current libvirt to pass arbitrary args to QEMU. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 13 5月, 2013 5 次提交
-
-
由 Daniel P. Berrange 提交于
The <filesystem> element can now accept a <driver type='nbd'/> as an alternative to 'loop'. The benefit of NBD is support for non-raw disk image formats. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Extend the <driver> element in filesystem devices to allow a storage format to be set. The new attribute uses 'format' to reflect the storage format. This is different from the <driver> element in disk devices which use 'type' to reflect the storage format. This is because the 'type' attribute on filesystem devices is already used for the driver backend, for which the disk devices use the 'name' attribute. Arggggh. Anyway for disks we have <driver name="qemu" type="raw"/> And for filesystems this change means we now have <driver type="loop" format="raw"/> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Osier Yang 提交于
-
由 Osier Yang 提交于
Since it's generic enough to be used by other types in future, I put it in <hostdev> as sub-element, though now it's only used by scsi host device.
-
由 Han Cheng 提交于
Except the scsi host device's controller is "lsilogic", mapping between the libvirt attributes and scsi-generic properties is: libvirt qemu ----------------------------------------- controller bus ($libvirt_controller.0) bus channel target scsi-id unit lun For scsi host device with "lsilogic" controller, the mapping is: ('target (libvirt)' must be 0, as it's not used; 'unit (libvirt) must <= 7). libvirt qemu ---------------------------------------------------------- controller && bus bus ($libvirt_controller.$libvirt_bus) unit scsi-id It's not good to hardcode/hard-check limits of these attributes, and even worse, these limits are not documented, one has to find out by either testing or reading the qemu code, I'm looking forward to qemu expose limits like these one day). For example, exposing "max_target", "max_lun" for megasas: static const struct SCSIBusInfo megasas_scsi_info = { .tcq = true, .max_target = MFI_MAX_LD, .max_lun = 255, .transfer_data = megasas_xfer_complete, .get_sg_list = megasas_get_sg_list, .complete = megasas_command_complete, .cancel = megasas_command_cancel, }; Example of the qemu command line (lsilogic controller): -drive file=/dev/sg2,if=none,id=drive-hostdev-scsi_host7-0-0-0 \ -device scsi-generic,bus=scsi0.0,scsi-id=8,\ drive=drive-hostdev-scsi_host7-0-0-0,id=hostdev-scsi_host7-0-0-0 Example of the qemu command line (virtio-scsi controller): -drive file=/dev/sg2,if=none,id=drive-hostdev-scsi_host7-0-0-0 \ -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=128,lun=128,\ drive=drive-hostdev-scsi_host7-0-0-0,id=hostdev-scsi_host7-0-0-0 Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: NOsier Yang <jyang@redhat.com>
-
- 07 5月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Use virBufferAddLit or virBufferAddChar instead.
-
由 Laine Stump 提交于
VFIO device assignment requires a cgroup ACL to be setup for access to the /dev/vfio/nn "group" device for any devices that will be assigned to a guest. In the case of a host device that is allocated from a pool, it was being allocated during qemuBuildCommandLine(), which is called by qemuProcessStart() *after* the all-encompassing qemuSetupCgroup() was called, meaning that the standard Cgroup ACL setup wasn't creating ACLs for these devices allocated from pools. One possible solution was to manually add a single ACL down inside qemuBuildCommandLine() when networkAllocateActualDevice() is called, but that has two problems: 1) the function that adds the cgroup ACL requires a virDomainObjPtr, which isn't available in qemuBuildCommandLine(), and 2) we really shouldn't be doing network device setup inside qemuBuildCommandLine() anyway. Instead, I've created a new function called qemuNetworkPrepareDevices() which is called just before qemuPrepareHostDevices() during qemuProcessStart() (explanation of ordering in the comments), i.e. well before the call to qemuSetupCgroup(). To minimize code churn in a patch that will be backported to 1.0.5-maint, qemuNetworkPrepareDevices only does networkAllocateActualDevice() and the bare amount of setup required for type='hostdev network devices, but it eventually should do *all* device setup for guest network devices. Note that some of the code that was previously needed in qemuBuildCommandLine() is no longer required when networkAllocateActualDevice() is called earlier: * qemuAssignDeviceHostdevAlias() is already done further down in qemuProcessStart(). * qemuPrepareHostdevPCIDevices() is called by qemuPrepareHostDevices() which is called after qemuNetworkPrepareDevices() in qemuProcessStart(). As hinted above, this new function should be moved into a separate qemu_network.c (or similarly named) file along with qemuPhysIfaceConnect(), qemuNetworkIfaceConnect(), and qemuOpenVhostNet(), and expanded to call those functions as well, then the nnets loop in qemuBuildCommandLine() should be reduced to only build the commandline string (which itself can be in a separate qemuInterfaceBuilldCommandLine() function as suggested by Michal). However, this will require storing away an array of tapfd and vhostfd that are needed for the commandline, so I would rather do that in a separate patch and leave this patch at the minimum to fix the bug.
-
- 03 5月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The use of () in a simple boolean comparison was not required Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 02 5月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
The source code base needs to be adapted as well. Some files include virutil.h just for the string related functions (here, the include is substituted to match the new file), some include virutil.h without any need (here, the include is removed), and some require both.
-
- 01 5月, 2013 1 次提交
-
-
由 John Ferlan 提交于
As a result of commit id '19c345f2', 'make -C tests valgrind' has the following for qemuxml2argvtest: ==22482== 197 (80 direct, 117 indirect) bytes in 1 blocks are definitely lost in loss record 101 of 120 ==22482== at 0x4A06B6F: calloc (vg_replace_malloc.c:593) ==22482== by 0x4C6F301: virAlloc (viralloc.c:124) ==22482== by 0x4C840FC: virSaveLastError (virerror.c:308) ==22482== by 0x431882: qemuBuildCommandLine (qemu_command.c:8204) ==22482== by 0x41E8F0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:155) ==22482== by 0x41FE9F: virtTestRun (testutils.c:157) ==22482== by 0x419DEB: mymain (qemuxml2argvtest.c:654) ==22482== by 0x4204DA: virtTestMain (testutils.c:719) ==22482== by 0x39D0821A04: (below main) (libc-start.c:225) ==22482==
-
- 30 4月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
qemuBuildMemballoonDevStr returns NULL if memballoon doesn't have the right address type, but it doesn't report an error, leading to: error: An error occurred, but the cause is unknown Report a helpful error message instead, e.g.: error: XML error: memballoon unsupported with address type 'usb'
-
- 29 4月, 2013 1 次提交
-
- 27 4月, 2013 5 次提交
-
-
由 Ján Tomko 提交于
Don't reserve slot 2 for video if the machine has no PCI buses. Error out when the user specifies a video device without a PCI address when there are no PCI buses. (This wouldn't work on a machine with no PCI bus anyway since we do add PCI addresses for video devices to the command line)
-
由 Ján Tomko 提交于
In the past we automatically added a USB controller and assigned it a PCI address (0:0:1.2) even on machines without a PCI bus. This didn't break machines with no PCI bus because the command line for it is just '-usb', with no mention of the PCI bus. The implicit IDE controller (reserved address 0:0:1.1) has no command line at all. Commit b33eb0dc removed the ability to reserve PCI addresses on machines without a PCI bus. This made them stop working, since there would always be the implicit USB controller. Skip the reservation of addresses for these controllers when there is no PCI bus, instead of failing.
-
由 Laine Stump 提交于
This isn't strictly speaking a bugfix, but I realized I'd gotten a bit too verbose when I chose the names for VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_*. This shortens them all a bit.
-
由 Paolo Bonzini 提交于
<source type='bridge'> uses a helper application to do the necessary TUN/TAP setup to use an existing network bridge, thus letting unprivileged users use TUN/TAP interfaces. However, libvirt should be preventing QEMU from running any setuid programs at all, which would include this helper program. From a security POV, any setuid helper needs to be run by libvirtd itself, not QEMU. This is what this patch does. libvirt now invokes the setuid helper, gets the TAP fd and then passes it to QEMU in the normal manner. The path to the helper is specified in qemu.conf. As a small advantage, this adds a <target dev='tap0'/> element to the XML of an active domain using <interface type='bridge'>. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Ján Tomko 提交于
Adjust the usb-none test, since it gives the memballoon a lower PCI slot now. Add a test for 'none' controller on s390, which doesn't have PCI buses.
-
- 26 4月, 2013 2 次提交
-
-
由 Laine Stump 提交于
VFIO requires all of the guest's memory and IO space to be lockable in RAM. The domain's max_balloon is the maximum amount of memory the domain can have (in KiB). We add a generous 1GiB to that for IO space (still much better than KVM device assignment, where the KVM module actually *ignores* the process limits and locks everything anyway), and convert from KiB to bytes. In the case of hotplug, we are changing the limit for the already existing qemu process (prlimit() is used under the hood), and for regular commandline additions of vfio devices, we schedule a call to setrlimit() that will happen after the qemu process is forked.
-
由 Laine Stump 提交于
The device option for vfio-pci is nearly identical to that for pci-assign - only the configfd parameter isn't supported (or needed). Checking for presence of the bootindex parameter is done separately from constructing the commandline, similar to how it is done for pci-assign. This patch contains tests to check for proper commandline construction. It also includes tests for parser-formatter-parser roundtrips (xml2xml), because those tests use the same data files, and would have failed had they been included before now. qemu: xml/args tests for VFIO hostdev and <interface type='hostdev'/> These should be squashed in with the patch that adds commandline handling of vfio (they would fail at any earlier time).
-