- 22 1月, 2018 4 次提交
-
-
由 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 21 次提交
-
-
由 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>
-
由 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>
-
由 Paolo Bonzini 提交于
Added in QEMU commits TBD and TBD. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 17 1月, 2018 4 次提交
-
-
由 intrigeri 提交于
/usr/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize libvirtd needs to be allowed to kill these processes, otherwise they remain running.
-
由 Marc Hartmayer 提交于
Add a check if it's a iSCSI hostdev and if it's not then don't use the union member 'iscsi'. The segmentation fault occured when accessing secinfo->type, but this can vary from case to case. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 Daniel P. Berrange 提交于
Update the min fedora to 26. Use a macro to record the min versions so that the later error message is always in sync with the earlier version check. Clarify the comment that refers to guessing of dist which does not actually happen. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Pavel Hrdina 提交于
RHEL-6 doesn't have bash-completion package by default, it has to be installed from EPEL. Reviewed-by: NDaniel P. Berrange <berrange@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 16 1月, 2018 2 次提交
-
-
由 Dan Zheng 提交于
Similar to commit @f44ec9c1, commit @500cbc06 introduced a new nested 'mdev_types' capability, however the mentioned commit didn't adjust virNodeDeviceNumOfCaps and virNodeDeviceListCaps functions accordingly to provide proper support for this capability. After applying this patch the following python snippet returns the expected results: import libvirt conn = libvirt.openReadOnly('qemu:///system') devs = conn.listAllDevices() for dev in devs: if 'mdev_types' in dev.listCaps(): print dev.name(),dev.numOfCaps(),dev.listCaps() Signed-off-by: NDan Zheng <dzheng@redhat.com> Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
Apparently we can't assume that people run readline recent enough to have rl_completion_quote_character (added in readline-5.0 released in 2011). However, we can't compile without it. So if not present, disable readline. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 15 1月, 2018 3 次提交
-
-
由 Michal Privoznik 提交于
The functions defined in these sources are referenced all over the place, however, compiler only when building with readline. Thus when building without it linker gets sad as it can't find them. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
When building without readline, this function does nothing but return false. Without touching any of its arguments which triggers a build error. Therefore, provide a stub that has arguments marked as unused. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Michal Privoznik 提交于
The current state of art is as follows: 1) vshReadlineOptionsGenerator() generate all possible --options for given command, and then 2) vshReadlineOptionsPrune() clears out already provided ones from the list. Not only this brings needless memory complexity it is also not trivial to get right. We can switch to easier approach: just don't add already specified --options in the first step. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-