- 24 1月, 2018 9 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This is a slight change from previous patches since virSecret does not have a name only UUID strings. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
The virConnectListAllNWFilters() has no extra flags yet, which simplifies things a bit. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Yet again, we don't need listing by device capabilities, so flags are unused. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This one is a bit simpler since virStoragePoolListAllVolumes() has no flags yet. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 23 1月, 2018 1 次提交
-
-
由 Chen Hanxiao 提交于
Provide more details related to the requirement that setting one of the values requires setting all of them. Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 22 1月, 2018 5 次提交
-
-
由 Michal Koutný 提交于
The libvirtd daemon uses systemd-machined D-Bus API when manipulating domains. The systemd-machined is D-Bus activated on demand. However, during system shutdown systemd-machined is stopped concurrently with libvirtd and virsh users also doing their final cleanup may transitively fail due to unavailability of systemd-machined. Example error message > libvirtd[1390]: 2017-12-20 18:55:56.182+0000: 32700: error : virSystemdTerminateMachine:503 : Refusing activation, D-Bus is shutting down. To circumvent this we need to explicitly specify both ordering and requirement dependency (to avoid late D-Bus activation) on systemd-machined. See [1] for the dependency debate. [1] https://lists.freedesktop.org/archives/systemd-devel/2018-January/040095.html
-
由 Laine Stump 提交于
We recently added a generic XHCI USB3 controller to QEMU, and libvirt supports adding that controller rather than the NEC XHCI USB3 controller, but when auto-adding a USB controller to Q35 domains we were still adding the vendor-specific NEC controller. This patch changes to add the generic controller instead, if it's available in the QEMU binary that will be used. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
It breaks the build and it is not really useful for anything. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Laine Stump 提交于
qemuDomainDefValidateVideo() (called from qemuDomainDefValidate()) is just a loop performing various checks on each video device. Rather than maintaining this separate function, just fold the validations into qemuDomainDeviceDefValidateVideo(), which is called once for each video device.
-
- 21 1月, 2018 1 次提交
-
-
由 Laine Stump 提交于
Commit 10c73bf1 fixed a bug that I had introduced back in commit 70249927 - if a vhost-scsi device had no manually assigned PCI address, one wouldn't be assigned automatically. There was a slight problem with the logic of the fix though - in the case of domains with pcie-root (e.g. those with a q35 machinetype), qemuDomainDeviceCalculatePCIConnectFlags() will attempt to determine if the host-side PCI device is Express or legacy by examining sysfs based on the host-side PCI address stored in hostdev->source.subsys.u.pci.addr, but that part of the union is only valid for PCI hostdevs, *not* for SCSI hostdevs. So we end up trying to read sysfs for some probably-non-existent device, which fails, and the function virPCIDeviceIsPCIExpress() returns failure (-1). By coincidence, the return value is being examined as a boolean, and since -1 is true, we still end up assigning the vhost-scsi device to an Express slot, but that is just by chance (and could fail in the case that the gibberish in the "hostside PCI address" was the address of a real device that happened to be legacy PCI). Since (according to Paolo Bonzini) vhost-scsi devices appear just like virtio-scsi devices in the guest, they should follow the same rules as virtio devices when deciding whether they should be placed in an Express or a legacy slot. That's accomplished in this patch by returning early with virtioFlags, rather than erroneously using hostdev->source.subsys.u.pci.addr. It also adds a test case for PCIe to assure it doesn't get broken in the future.
-
- 20 1月, 2018 1 次提交
-
-
由 Jim Fehlig 提交于
Commit 8708ca01 added virNetDevSwitchdevFeature() to check if a network device has Switchdev capabilities. virNetDevSwitchdevFeature() attempts to retrieve the PCI device associated with the network device, ignoring non-PCI devices. It does so via the following call chain virNetDevSwitchdevFeature()->virNetDevGetPCIDevice()-> virPCIGetDeviceAddressFromSysfsLink() For non-PCI network devices (qeth, Xen vif, etc), virPCIGetDeviceAddressFromSysfsLink() will report an error when virPCIDeviceAddressParse() fails. virPCIDeviceAddressParse() also logs an error. After commit 8708ca01 there are now two errors reported for each non-PCI network device even though the errors are harmless. To avoid the errors, introduce virNetDevIsPCIDevice() and use it in virNetDevGetPCIDevice() before attempting to retrieve the associated PCI device. virNetDevIsPCIDevice() uses the 'subsystem' property of the device to determine if it is PCI. See the sysfs rules in kernel documentation for more details https://www.kernel.org/doc/html/latest/admin-guide/sysfs-rules.html
-
- 19 1月, 2018 4 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1536461 This reverts commit aeda1b8c. Problem is that we need mon->lastError to be set because it's used all over the place. Also, there's nothing wrong with reporting error if one occurred. I mean, if there's a thread executing an API and which currently is talking on monitor it definitely wants the error reported. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel Veillard 提交于
* docs/news.xml: update for release * po/*.po*: regenerated
-
由 Jiri Denemark 提交于
When migrating a shutoff domain (i.e., offline migration), we have no statistics to report and thus jobInfo will be NULL in qemuMigrationFinish. Broken by me in v3.10.0-183-ge8784e78. https://bugzilla.redhat.com/show_bug.cgi?id=1536351Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 18 1月, 2018 19 次提交
-
-
由 Jiri Denemark 提交于
This is a variant of EPYC with indirect branch prediction protection. The only difference between EPYC and EPYC-IBPB is the added "ibpb" feature. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Ján Tomko 提交于
After the latest CPU additions, the build fails with clang: cputest.c:905:1: error: stack frame size of 26136 bytes in function 'mymain' [-Werror,-Wframe-larger-than=] Raise the relaxed limit which is used for tests.
-
由 Daniel P. Berrange 提交于
We read from QEMU until seeing a \r\n pair to indicate a completed reply or event. To avoid memory denial-of-service though, we must have a size limit on amount of data we buffer. 10 MB is large enough that it ought to cope with normal QEMU replies, and small enough that we're not consuming unreasonable mem. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
As usual, a bunch of changes slipped through the cracks during the development cycle. Update the release notes to include at least the most notable ones. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Marc Hartmayer 提交于
Commit 7a931a42 refactored the code and probably forgot to add this line. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 Jiri Denemark 提交于
This is a variant of Skylake-Server with indirect branch prediction protection. The only difference between Skylake-Server and Skylake-Server-IBRS is the added "spec-ctrl" feature. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Skylake-Client with indirect branch prediction protection. The only difference between Skylake-Client and Skylake-Client-IBRS is the added "spec-ctrl" feature. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Broadwell with indirect branch prediction protection. The only difference between Broadwell and Broadwell-IBRS is the added "spec-ctrl" feature. The Broadwell-IBRS model in QEMU is a bit different since Broadwell got several additional features since we added it in cpu_map.xml: abm, arat, f16c, rdrand, vme, xsaveopt Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Broadwell-noTSX with indirect branch prediction protection. The only difference between Broadwell-noTSX and Broadwell-noTSX-IBRS is the added "spec-ctrl" feature. The Broadwell-noTSX-IBRS model in QEMU is a bit different since Broadwell-noTSX got several additional features since we added it in cpu_map.xml: abm, arat, f16c, rdrand, vme, xsaveopt Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Haswell with indirect branch prediction protection. The only difference between Haswell and Haswell-IBRS is the added "spec-ctrl" feature. The Haswell-IBRS model in QEMU is a bit different since Haswell got several additional features since we added it in cpu_map.xml: arat, abm, f16c, rdrand, vme, xsaveopt Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Haswell-noTSX with indirect branch prediction protection. The only difference between Haswell-noTSX and Haswell-noTSX-IBRS is the added "spec-ctrl" feature. The Haswell-noTSX-IBRS model in QEMU is a bit different since Haswell-noTSX got several additional features since we added it in cpu_map.xml: arat, abm, f16c, rdrand, vme, xsaveopt Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of IvyBridge with indirect branch prediction protection. The only difference between IvyBridge and IvyBridge-IBRS is the added "spec-ctrl" feature. The IvyBridge-IBRS model in QEMU is a bit different since IvyBridge got several additional features since we added it in cpu_map.xml: arat, vme, xsaveopt Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of SandyBridge with indirect branch prediction protection. The only difference between SandyBridge and SandyBridge-IBRS is the added "spec-ctrl" feature. The SandyBridge-IBRS model in QEMU is a bit different since SandyBridge got several additional features since we added it in cpu_map.xml: arat, vme, xsaveopt Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Westmere with indirect branch prediction protection. The only difference between Westmere and Westmere-IBRS is the added "spec-ctrl" feature. The Westmere-IBRS model in QEMU is a bit different since Westmere got several additional features since we added it in cpu_map.xml: arat, pclmuldq, vme Adding them only to the -IBRS variant would confuse our CPU detection code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
This is a variant of Nehalem with indirect branch prediction protection. The only difference between Nehalem and Nehalem-IBRS is the added "spec-ctrl" feature. Thus the diff matches QEMU, but the new CPU model itself is different. The QEMU's versions of both models contain "vme" feature, while this feature is missing in libvirt's models. While we can't change the existing Nehalem CPU model, we could add "vme" to Nehalem-IBRS to make it similar to QEMU, but doing so would fool our CPU detecting code so that any Nehalem CPU with "vme" feature would be detected as Nehalem-IBRS CPU without spec-ctrl. Not adding "vme" to Nehalem-IBRS is safe as QEMU will just provide the feature anyway, which matches what happens with Nehalem (and new enough machine types). Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
The CPU contains the updated microcode for CVE-2017-5715. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
The CPU contains the updated microcode for CVE-2017-5715. The *-guest.xml and *-json.xml CPU definitions use Skylake-Client CPU model rather than Broadwell. This is similar to Xeon-E5-2650-v4 and it is caused by our CPU model selection code when no model matches the CPU signature (family + model). We'd need to maintain a complete list of CPU signatures for our CPU models to fix this. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-