- 03 4月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
Depending on the architecture, requirements for ACPI and UEFI can be different; more specifically, while on x86 UEFI requires ACPI, on aarch64 it's the other way around. Enforce these requirements when validating the domain, and make the error message more accurate by mentioning that they're not necessarily applicable to all architectures. Several aarch64 test cases had to be tweaked because they would have failed the validation step otherwise.
-
- 28 3月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
Instead of having a separate function, we can simply return zero from the existing qemuDomainGetMemLockLimitBytes() to signal the caller that the memory locking limit doesn't need to be set for the guest. Having a single function instead of two makes it less likely that we will use the wrong value, which is exactly what happened when we started applying the limit that was meant for VFIO-using guests to <memoryBacking><locked>-using guests.
-
由 Jiri Denemark 提交于
QEMU allows for TSC frequency to be explicitly set to enable migration with invtsc (migration fails if the destination QEMU cannot set the exact same frequency used when starting the domain on the source host). Libvirt already supports setting the TSC frequency in the XML using <clock> <timer name='tsc' frequency='1234567890'/> </clock> which will be transformed into -cpu Model,tsc-frequency=1234567890 QEMU command line. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 3月, 2017 1 次提交
-
-
由 Erik Skultety 提交于
Format the mediated devices on the qemu command line as -device vfio-pci,sysfsdev='/path/to/device/in/syfs'. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 17 3月, 2017 4 次提交
-
-
由 Peter Krempa 提交于
The disk tuning group parameter is ignored by qemu if no other throttling options are set. Reject such configuration, since the name would not be honored after setting parameters via the live tuning API. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1433180
-
由 Peter Krempa 提交于
When checking capabilities for qemu we need to check whether subsets of the disk throttling settings are supported. Extract the checks into a separate functions as they will be reused in next patch.
-
由 Peter Krempa 提交于
qemuBuildDriveStr grew into 'megamoth' proportions. Cut out some parts.
-
由 Andrea Bolognani 提交于
QEMU 2.9 introduces the pcie-root-port device, which is a generic version of the existing ioh3420 device. Make the new device available to libvirt users.
-
- 15 3月, 2017 8 次提交
-
-
由 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>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So, majority of the code is just ready as-is. Well, with one slight change: differentiate between dimm and nvdimm in places like device alias generation, generating the command line and so on. Speaking of the command line, we also need to append 'nvdimm=on' to the '-machine' argument so that the nvdimm feature is advertised in the ACPI tables properly. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 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>
-
由 Michal Privoznik 提交于
Frankly, this function is one big mess. A lot of arguments, complicated behaviour. It's really surprising that arguments were in random order (input and output arguments were mixed together), the documentation was outdated, the description of return values was bogus. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Even though this variable contains just values from an enum where zero has the usual meaning, it's enum after all and we should check it as such. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is an input argument. We should not overwrite it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 3月, 2017 1 次提交
-
-
由 Fabian Freyer 提交于
bhyve supports 'gop' video device that allows clients to connect to VMs using VNC clients. This commit adds support for that to the bhyve driver: - Introducr 'gop' video device type - Add capabilities probing for the 'fbuf' device that's responsible for graphics - Update command builder routines to let users configure domain's VNC via gop graphics. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
- 10 3月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
This reverts commit c96bd78e. So our code is one big mess and we modify domain definition while building qemu_command line and our hotplug code share only part of the parsing and command line building code. Let's revert that change because to fix it properly would require refactor and move a lot of things. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430275
-
- 09 3月, 2017 1 次提交
-
-
由 Philipp Hahn 提交于
QEMU should be written all upper or all lower case.
-
- 06 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Now that we have some qemuSecurity wrappers over virSecurityManager APIs, lets make sure everybody sticks with them. We have them for a reason and calling virSecurityManager API directly instead of wrapper may lead into accidentally labelling a file on the host instead of namespace. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 02 3月, 2017 1 次提交
-
-
由 Peter Krempa 提交于
Our documentation states that the chardev logging file is truncated unless append='on' is specified. QEMU also behaves the same way and truncates the file unless we provide the argument. The new virlogd implementation did not honor if the argument was missing and continued to append to the file. Truncate the file even when the 'append' attribute is not present to behave the same with both implementations and adhere to the docs. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1420205
-
- 24 2月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1352529Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 23 2月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
qemuDomainAssignPCIAddresses() hardcoded the assumption that the only way to support devices on a non-zero bus is to add one or more pci-bridges; however, since we now support a large selection of PCI controllers that can be used instead, the assumption is no longer true. Moreover, this check was always redundant, because the only sensible time to check for the availability of pci-bridge is when building the QEMU command line, and such a check is of course already in place. In fact, there were *two* such checks, but since one of the two was relying on the incorrect assumption explained above, and it was redundant anyway, it has been dropped.
-
由 Andrea Bolognani 提交于
When switching over the values in the virDomainControllerModelPCI enumeration, make sure the proper cast is in place so that the compiler can warn us when the coverage is not exaustive. For the same reason, fold some unstructured checks (performed by comparing directly against some values in the enumeration) inside an existing switch statement.
-
- 22 2月, 2017 1 次提交
-
-
由 John Ferlan 提交于
It's not really 'Chardev' specific - we can reuse this for other objects. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 21 2月, 2017 2 次提交
-
-
由 Pavel Hrdina 提交于
This will ensure that IOThreads are properly validated while a domain is defined. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 17 2月, 2017 1 次提交
-
-
由 Marc-André Lureau 提交于
Add a new attribute 'rendernode' to <gl> spice element. Give it to QEMU if qemu supports it (queued for 2.9). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 09 2月, 2017 3 次提交
-
-
由 Jaroslav Safka 提交于
This patch add support for file memory backing on numa topology. The specified access mode in memoryBacking can be overriden by specifying token memAccess in numa cell.
-
由 Jaroslav Safka 提交于
Rename to avoid duplicate code. Because virDomainMemoryAccess will be used in memorybacking for setting default behaviour. NOTE: The enum cannot be moved to qemu/domain_conf because of headers dependency
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 08 2月, 2017 1 次提交
-
-
由 Laine Stump 提交于
libvirt was able to set the host_mtu option when an MTU was explicitly given in the interface config (with <mtu size='n'/>), set the MTU of a libvirt network in the network config (with the same named subelement), and would automatically set the MTU of any tap device to the MTU of the network. This patch ties that all together (for networks based on tap devices and either Linux host bridges or OVS bridges) by learning the MTU of the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and returning that value so that it can then be passed to qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the interface's commandline options. The result is that a higher MTU for all guests connecting to a particular network will be plumbed top to bottom by simply changing the MTU of the network (in libvirt's config for libvirt-managed networks, or directly on the bridge device for simple host bridges or OVS bridges managed outside of libvirt). One question I have about this - it occurred to me that in the case of migrating a guest from a host with an older libvirt to one with a newer libvirt, the guest may have *not* had the host_mtu option on the older machine, but *will* have it on the newer machine. I'm curious if this could lead to incompatibilities between source and destination (I guess it all depends on whether or not the setting of host_mtu has a practical effect on a guest that is already running - Maxime?) Likewise, we could run into problems when migrating from a newer libvirt to older libvirt - The guest would have been told of the higher MTU on the newer libvirt, then migrated to a host that didn't understand <mtu size='blah'/>. (If this really is a problem, it would be a problem with or without the current patch).
-
- 30 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
==12618== 110 bytes in 10 blocks are definitely lost in loss record 269 of 295 ==12618== at 0x4C2AE5F: malloc (vg_replace_malloc.c:297) ==12618== by 0x1CFC6DD7: vasprintf (vasprintf.c:73) ==12618== by 0x1912B2FC: virVasprintfInternal (virstring.c:551) ==12618== by 0x1912B411: virAsprintfInternal (virstring.c:572) ==12618== by 0x50B1FF: qemuAliasChardevFromDevAlias (qemu_alias.c:638) ==12618== by 0x518CCE: qemuBuildChrChardevStr (qemu_command.c:4973) ==12618== by 0x522DA0: qemuBuildShmemBackendChrStr (qemu_command.c:8674) ==12618== by 0x523209: qemuBuildShmemCommandLine (qemu_command.c:8789) ==12618== by 0x526135: qemuBuildCommandLine (qemu_command.c:9843) ==12618== by 0x48B4BA: qemuProcessCreatePretendCmd (qemu_process.c:5897) ==12618== by 0x4378C9: testCompareXMLToArgv (qemuxml2argvtest.c:498) ==12618== by 0x44D5A6: virTestRun (testutils.c:180) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Not only we should set the MTU on the host end of the device but also let qemu know what MTU did we set. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 07 1月, 2017 2 次提交
-
-
由 Maxim Nestratov 提交于
Separate out the "policy=discard" into it's own specific qemu command line. We'll rename "kvm-pit-device" test case to be "kvm-pit-discard" since it has the syntax we'd be using. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
By a mistake, for the VIR_DOMAIN_TIMER_TICKPOLICY_DELAY qemu command line creation, 'discard' was used instead of 'delay' in commit id '1569fa14'. Test "kvm-pit-delay" is fixed accordingly to show the correct option being generated. Remove the (now) redundant kvm-pit-device tests. As it turns out there is no need to specify both QEMU_CAPS_NO_KVM_PIT and QEMU_CAPS_KVM_PIT_TICK_POLICY since they are mutually exclusive and "kvm-pit-device" becomes just the same as "kvm-pit-delay". Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
- 06 1月, 2017 1 次提交
-
-
由 Collin L. Walling 提交于
Qemu has abandoned the +/-feature syntax in favor of key=value. Some architectures (s390) do not support +/-feature. So we update libvirt to handle both formats. If we detect a sufficiently new Qemu (indicated by support for qmp query-cpu-model-expansion) we use key=value else we fall back to +/-feature. Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
-
- 04 1月, 2017 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1405269 If a secret was not provided for what was determined to be a LUKS encrypted disk (during virStorageFileGetMetadata processing when called from qemuDomainDetermineDiskChain as a result of hotplug attach qemuDomainAttachDeviceDiskLive), then do not attempt to look it up (avoiding a libvirtd crash) and do not alter the format to "luks" when adding the disk; otherwise, the device_add would fail with a message such as: "unable to execute QEMU command 'device_add': Property 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'" because of assumptions that when the format=luks that libvirt would have provided the secret to decrypt the volume. Access to unlock the volume will thus be left to the application.
-
- 08 12月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
If you've ever tried running a huge page backed guest under different user than in qemu.conf, you probably failed. Problem is even though we have corresponding APIs in the security drivers, there's no implementation and thus we don't relabel the huge page path. But even if we did, so far all of the domains share the same path: /hugepageMount/libvirt/qemu Our only option there would be to set 0777 mode on the qemu dir which is totally unsafe. Therefore, we can create dir on per-domain basis, i.e.: /hugepageMount/libvirt/qemu/domainName and chown domainName dir to the user that domain is configured to run under. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-