- 14 4月, 2020 7 次提交
-
-
由 Seeteena Thoufeek 提交于
Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Seeteena Thoufeek 提交于
This is the last missing g_autofree conversion change in the module after commit 1e2ae2e3 took care of the VIR_AUTOFREE conversion. Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Andrea Bolognani 提交于
Travis CI reports root: deprecated key sudo (The key `sudo` has no effect anymore.) so let's drop it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
All information, except for osx_image image, is identical between the two jobs so we can avoid repeating it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
The newly-introduced CONTRIBUTING.rst serves the same purposes and lives in the path where most people would look for it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
It's generally expected that a git repository will contain this file, which serves as an entry point for people interested in contributing to the project. In our case, we have extensive documentation available on the website which we don't want to duplicate, so let's just point people there. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
getaddrinfo returns linked list. Fix iteration accordingly. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
- 13 4月, 2020 10 次提交
-
-
由 Laine Stump 提交于
Before this patch we would simply rely on QEMU failing to attach the device. Since we have a flag in the address set telling us which controllers support hotplug, we can fail the operation sooner. This also assures that when hotplugging with no provided PCI address, that we skip any controllers with hotplug='off', and attempt to assign the device to a controller that not only supports hotplug, but also has it enabled. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
The HOTPLUGGABLE flag is set for appropriates buses in a PCI address set, and thnis patch updates virDomainPCIAddressFlagsCompatible() to check the HOTPLUGGABLE flag when searching for a suitable bus/slot for a device. No devices request HOTPLUGGABLE though (yet), so there is no observable effect. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
virDomainPCIAddressBusSetModel() is called for each PCI controller when building an address set prior to assiging PCI addresses to devices. This patch adds a new argument, allowHotplug, to that function that can be set to false if we know for certain that a particular controller won't support hotplug The most interesting case is in qemuDomainPCIAddressSetCreate(), where the config of each existing controller is available while building the address set, so we can appropriately set allowHotplug = false when the user has "hotplug='off'" in the config of a controller that normally would support hotplug. In all other cases, it is set to true or false in accordance with the capability of the controller model. So far we aren't doing anything with this bus flag in the address set. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
Old behavior: If the address was manually provided by config, copy device AUTOASSIGN flag into the bus flag, and then later on in the function *always* check for a match of the flags (which will always match if the address came from config, since we just copied it). New behavior: Don't mess with the bus flags - just directly check if the AUTOASSIGN flag matches in bus and dev, but only make the check if the address didn't come from config (i.e. it was auto-assigned by libvirt). Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
When the HOTPLUGGABLE flag was originally added, it was set for all the PCI controllers that accepted hotplugged devices, and requested for all devices that were auto-assigned to a controller. While we're still autoassigning to the same list of controllers, those controllers may or may not support hotplug, so let's use the flag that fits what we're actually doing. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
This new flag will be set for any controller that we decide can have devices assigned to it automatically during PCI device assignment. In the past PCI_CONNECT_TYPE_HOTPLUGGABLE was used for this purpose, but that is overloading that flag, and no longer technically correct; what we *really* want is to auto-assign devices to any pcie-root-port or pcie-switch-downstream-port regardless of whether or not that controller happens to have hotplug enabled. This patch just adds the flag, but doesn't use it at all. Note that the numbering of all the other flags was changed in order to insert the new flag near the beginning of the list; that doesn't cause any problem because the connect flags aren't stored anywhere between runs of libvirtd. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
If a pcie-root-port or pcie-downstream-port has hotplug='off' in its <target> subelement, and if the qemu binary supports the hotplug=false option, then it will be added to the commandline for the pcie controller. This controller will then not allow any hotplug/unplug of devices while the guest is running (and the hotplug capability won't be advertised to the guest OS, so the guest OS also won't present unplugging of PCI devices as an option). <controller type='pci' model='pcie-root-port'> <target hotplug='off'/> </controller> For any PCI controllers other than pcie-downstream-port and pcie-root-port, of for qemu binaries that don't support the hotplug commandline option, an error will be logged during validation. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
a <controller type='pci'...> element can now have a "hotplug" attribute in the <target> subelement. This is intended to control whether or not the slot(s) of the controller support hotplugging/unplugging a device: <controller type='pci' model='pcie-root-port'> <target hotplug='off'/> </controller> The default value of hotplug is "on". Since support for configuring such an option is hypervisor-dependent (and will vary among different types of PCI controllers even on a single hypervisor), no validation is done in this patch - that validation will be done in the patch that wires support for the setting into the hypervisor. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
This caps flag is set when the qemu binary supports the option "hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and xio3130-downstream (Intel pcie-downstream-port). If it's available, it's possible to disable hotplugging/unplugging devices on a particular port by adding ",hotplug=off" to the qemu device commandline. This option first appears in qemu-5.0.0. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 4月, 2020 5 次提交
-
-
由 Daniel Henrique Barboza 提交于
In a guest with only one vcpu, when pinning the emulator in say CPU184 and the vcpu0 in CPU0 of the host, the user might expect that only CPU0 and CPU184 of the host will be used by the guest. The reality is that Libvirt takes some time to honor the emulator and vcpu pinning, taking care of NUMA constraints first. This will result in other CPUs of the host being potentially used by the QEMU thread until the emulator/vcpu pinning is done. The user then might be confused by the output of 'virsh cpu-stats' in this scenario, showing around 200 microseconds of cycles being spent in other CPUs. Let's document this behavior, which is explained in detail in Libvirt commit v5.0.0-199-gf136b831, in the cputune section of formatdomain.html.in. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Jim Fehlig 提交于
Add support in the domXML<->native config converter for max_event_channels. The parser and formater functions for max_grant_frames were reworked to also parse max_event_channels. In doing so the xenbus controller is added earlier in the config parsing, requiring a small adjustment to one of the existing tests. Include a new test for the event channel conversion. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jim Fehlig 提交于
Add support for setting event_channels in libxl domain config object and include a test to check that it is properly converted from XML to libxl domain config. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jim Fehlig 提交于
Event channels are like PV interrupts and in conjuction with grant frames form a data transfer mechanism for PV drivers. They are also used for inter-processor interrupts. Guests with a large number of vcpus and/or many PV devices many need to increase the maximum default value of 1023. For this reason the native Xen config format supports the 'max_event_channels' setting. See xl.cfg(5) man page for more details. Similar to the existing maxGrantFrames option, add a new xenbus controller option 'maxEventChannels', allowing to adjust the maximum value via libvirt. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
One new company has contributed to libvirt since the last time the gitdm configuration was updated. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 4月, 2020 7 次提交
-
-
由 Daniel P. Berrangé 提交于
Help people to see where to report bugs when they download a libvirt release. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
To discourage people from using the git mirror links, style them in a smaller italic font, with plain colour. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Change the download page so that gitlab is referred to as the primary git host and libvirt.org is related to mirror status. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Currently we use the "Virtualization Tools" product in Red Hat Bugzilla for issue tracking upstream. This changes to point people to GitLab for issue tracking. Note that Bugzilla still has plenty of bugs present against libvirt. Triaging these to determine what is still valid will be a separate exercise. Bugzilla will be locked to prevent creation of new issues meanwhile. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The libvirt project has alot of git repositories, and they must all be configured in the same way, more or less. This page documents the settings changes that I have made in GitLab and GitHub when configuring projects, both as a reminder for myself, and to help anyone else doing the same in future. Also included is info about the repo mirroring on the libvirt.org server. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
To encourage contributors to make changes to the main website, add a footer link to every page which links to the corresponding source file in git. With gitlab, they are able to edit content directly in the web browser and then submit a merge request. This gives a way to contribute content that is arguably easier than our wiki which requires manual account creation, while this will also benefit from maintainer review. Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 08 4月, 2020 11 次提交
-
-
由 Jiri Denemark 提交于
The signatures of these two CPU model differ only in stepping as both report family 6 and model 85. Skylake-Server uses stepping 4 or less and Cascadelake-Server uses stepping 5..7. https://bugzilla.redhat.com/show_bug.cgi?id=1761678Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Skylake-Server with family 6, model 85, stepping 4, which is currently mis-detected as Cascadelake-Server CPU model. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Cascadelake-Server with family 6, model 85, stepping 7. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
CPU models defined in the cpu_map can use signature/@stepping attribute to match a limited set of stepping numbers. The value is a bitmap for bits 0..15 each corresponding to a single stepping value. For example, stepping='4-6,9' will match 4, 5, 6, and 9. Omitting the attribute is equivalent to stepping='0-15'. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Thanks to glib allocation functions which abort on OOM the function cannot ever return NULL. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
The CPU models in our cpu_map define their signatures using separate family and model numbers. Let's store the signatures in the same way in our runtime representation of the cpu_map. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
It can be used for separating family, model, and stepping numbers from a single 32b integer as reported by CPUID. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
The function will be used for freeing virCPUx86Signatures structure introduced later in this series. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Later in this series the function will work on a newly introduced virCPUx86Signatures structure. Let's move it to the place where all related functions will be added and rename the function as virCPUx86SignaturesFormat for easier review of the virCPUx86Signatures patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Later in this series the function will work on a newly introduced virCPUx86Signatures structure. Let's move it to the place were all related functions will be added and rename the function as virCPUx86SignaturesMatch for easier review of the virCPUx86Signatures patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Later in this series the function will work on a newly introduced virCPUx86Signatures structure. Let's move it to the place were all related functions will be added and rename the function as virCPUx86SignaturesCopy for easier review of the virCPUx86Signatures patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-