[libvirt] [PATCH v2 2/4] util: new function virPCIDeviceGetConfigPath()

The path to the config file for a PCI device is conventiently stored in a virPCIDevice object, but that object's contents aren't directly visible outside of virpci.c, so we need to have an accessor function for it if anyone needs to look at it. --- New in "V2" src/libvirt_private.syms | 1 +

[libvirt] [PATCH v2 4/4] qemu: assign vfio devices to PCIe addresses when appropriate

Although nearly all host devices that are assigned to guests using vfio ("" devices in libvirt) are physically PCI Express devices, until now libvirt's PCI address assignment has always assigned them addresses on legacy PCI controllers in the guest, even if the guest's machinetype has a PCIe root

[libvirt] [PATCH v2 3/4] qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags

If libvirtd is running unprivileged, it can open a device's PCI config data in sysfs, but can only read the first 64 bytes. But as part of determining whether a device is Express or legacy PCI, qemuDomainDeviceCalculatePCIConnectFlags() will be updated in a future patch to call

[libvirt] [PATCH v2 1/4] util: new function virFileLength()

This new function just calls stat() and returns st_size (or -1 if there is an error). We may decide we want this function to be more complex, and handle things like block devices - this is a placeholder (that works) for any more complicated funtion. NB: virFileLength() takes a path rather than an

[libvirt] [PATCH v2 0/4] qemu: assign vfio devices to PCIe addresses when appropriate

Patches 1 and 4 were originally added to the end of the "more PCIe less legacy PCI" patchset in its final incarnation, but all the other patches were ACKed and pushed, while this needed a bit more work, resulting in this "faux V2" - although it's the 2nd time I've posted these patches, their "V1"

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On 18/11/16 19:17, Andrea Bolognani wrote: > On Thu, 2016-11-17 at 13:02 +1100, Alexey Kardashevskiy wrote: >>> That said, considering that a big part of the PCI address >>> allocation logic is based off whether the specific machine >>> type exposes a legay PCI Root Bus or a PCI Express Root Bus,

Re: [libvirt] [PATCH] libxl: add tunnelled migration support

On 11/19/2016 08:22 AM, Jim Fehlig wrote: > On 11/10/2016 09:14 PM, Bob Liu wrote: >> Tunnelled migration doesn't require any extra network connections beside the >> libvirt daemon. >> It's capable of strong encryption and the default option of openstack-nova. >> >> This patch adds the tunnelled

[libvirt] [PATCH v2 26/31] tests: Update capabilities for QEMU 2.6.0 (aarch64, GICv3)

Signed-off-by: Jiri Denemark --- .../qemu_2.6.0-gicv3-virt.aarch64.xml | 6 +- tests/domaincapstest.c | 2 +- .../caps_2.6.0-gicv3.aarch64.replies | 125 +++-- .../caps_2.6.0-gicv3.aarch64.xml

[libvirt] [PATCH v2 30/31] tests: Add QEMU 2.8.0 domain capabilities tests

Signed-off-by: Jiri Denemark --- .../domaincapsschemadata/qemu_2.8.0-tcg.x86_64.xml | 116 + tests/domaincapsschemadata/qemu_2.8.0.x86_64.xml | 116 + tests/domaincapstest.c | 8 ++ 3 files changed, 240

[libvirt] [PATCH v2 19/31] tests: Update capabilities for QEMU 1.7.0

Signed-off-by: Jiri Denemark --- tests/domaincapsschemadata/qemu_1.7.0.x86_64.xml | 4 +- tests/domaincapstest.c | 2 +- .../qemucapabilitiesdata/caps_1.7.0.x86_64.replies | 88 +-

[libvirt] [PATCH v2 23/31] tests: Update capabilities for QEMU 2.6.0

Signed-off-by: Jiri Denemark --- tests/domaincapsschemadata/qemu_2.6.0.x86_64.xml | 4 +- tests/domaincapstest.c | 2 +- .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 100 -

[libvirt] [PATCH v2 21/31] tests: Update capabilities for QEMU 2.4.0

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 100 - tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 30 ++- 2 files changed, 127 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 05/31] qemu: Enable KVM when probing capabilities

CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities:

[libvirt] [PATCH v2 22/31] tests: Update capabilities for QEMU 2.5.0

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 100 - tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 30 ++- 2 files changed, 127 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 01/31] qemu: Make QMP probing process reusable

The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); mon = virQEMUCapsInitQMPCommandRun(cmd,

[libvirt] [PATCH v2 02/31] qemu: Use -machine when probing capabilities via QMP

Using -machine instead of -M for QMP probing is safe because any QEMU binary which is capable of QMP probing supports -machine. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[libvirt] [PATCH v2 25/31] qemu: Avoid reporting "host" as a supported CPU model

"host" CPU model is supported by a special host-passthrough CPU mode and users is not allowed to specify this model directly with custom mode. Thus we should not advertise "host" CPU model in domain capabilities. This worked well on architectures for which libvirt provides a list of supported CPU

[libvirt] [PATCH v2 31/31] qemu: Add support for unavailable-features

QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the

[libvirt] [PATCH v2 17/31] tests: Update capabilities for QEMU 1.5.3

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_1.5.3.x86_64.replies | 88 +- tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 26 ++- 2 files changed, 111 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 24/31] tests: Update capabilities for QEMU 2.6.0 (aarch64, GICv2)

Signed-off-by: Jiri Denemark --- .../qemu_2.6.0-gicv2-virt.aarch64.xml | 5 +- tests/domaincapsschemadata/qemu_2.6.0.aarch64.xml | 5 +- tests/domaincapstest.c | 4 +- .../caps_2.6.0-gicv2.aarch64.replies | 112

[libvirt] [PATCH v2 27/31] tests: Update capabilities for QEMU 2.6.0 (ppc64le)

Signed-off-by: Jiri Denemark --- tests/domaincapsschemadata/qemu_2.6.0.ppc64le.xml |5 +- tests/domaincapstest.c |2 +- .../caps_2.6.0.ppc64le.replies | 1324 +++-

[libvirt] [PATCH v2 18/31] tests: Update capabilities for QEMU 1.6.0

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_1.6.0.x86_64.replies | 88 +- tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 26 ++- 2 files changed, 111 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 16/31] tests: Update capabilities for QEMU 1.4.2

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_1.4.2.x86_64.replies | 88 +- tests/qemucapabilitiesdata/caps_1.4.2.x86_64.xml | 26 ++- 2 files changed, 111 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 07/31] qemu: Use saner defaults for domain capabilities

When domain capabilities were introduced we did not have enough data to decide whether KVM works on the host or not and thus working legacy/VFIO device assignment was used as a witness. Now that we know whether KVM was enabled when probing QEMU capabilities (and thus we know it's working), we can

[libvirt] [PATCH v2 28/31] tests: Update capabilities for QEMU 2.7.0

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 103 - tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 31 ++- 2 files changed, 131 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 09/31] qemu: Refactor virQEMUCapsCacheLookup

The function is made a little bit more readable and the code which refreshes cached capabilities if they are not valid any more was moved into a separate function (virQEMUCapsCacheValidate) so that it can be reused in other places. Signed-off-by: Jiri Denemark ---

[libvirt] [PATCH v2 10/31] qemu: Refresh caps in virQEMUCapsCacheLookupByArch

The function just returned cached capabilities without checking whether they are still valid. We should check that and refresh the capabilities to make sure we don't return stale data. In other words, we should do what all other lookup functions do. Signed-off-by: Jiri Denemark

[libvirt] [PATCH v2 00/31] qemu: Add support for unavailable-features

QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the

[libvirt] [PATCH v2 12/31] qemu: Introduce virQEMUCapsFormatCPUModels

This patch moves the CPU models formatting code from virQEMUCapsFormatCache into a separate function. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git

[libvirt] [PATCH v2 14/31] tests: Update capabilities for QEMU 1.2.2

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_1.2.2.x86_64.replies | 80 +- tests/qemucapabilitiesdata/caps_1.2.2.x86_64.xml | 24 ++- 2 files changed, 102 insertions(+), 2 deletions(-) diff --git

[libvirt] [PATCH v2 04/31] qemucapsprobe: Ignore all greetings except the first one

When starting QEMU more than once during a single probing process, qemucapsprobe utility would save QMP greeting several times, which doesn't play well with our test monitor. Signed-off-by: Jiri Denemark --- tests/qemucapsprobemock.c | 9 +++-- 1 file changed, 7

[libvirt] [PATCH v2 06/31] qemu: Discard caps cache when KVM availability changes

Since some may depend on the accelerator used when probing QEMU the cache becomes invalid when KVM becomes available or if it is not available anymore. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 37 -

[libvirt] [PATCH v2 13/31] qemu: Probe CPU models for KVM and TCG

CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid

[libvirt] [PATCH v2 08/31] qemu: Don't return unusable virttype in domain capabilities

If a user asked for a KVM domain capabilities when KVM is not available, we would happily return data we got when probing through TCG and pretended they were relevant for KVM. Let's just report KVM is not supported to avoid confusion. Signed-off-by: Jiri Denemark ---

[libvirt] [PATCH v2 20/31] tests: Update capabilities for QEMU 2.1.1

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies | 91 +- tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 27 ++- 2 files changed, 115 insertions(+), 3 deletions(-) diff --git

[libvirt] [PATCH v2 11/31] qemu: Introduce virQEMUCapsLoadCPUModels

This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 70 +--- 1 file changed, 47 insertions(+), 23 deletions(-) diff --git

[libvirt] [PATCH v2 03/31] qemu: Probe KVM state earlier

Let's set QEMU_CAPS_KVM and QEMU_CAPS_ENABLE_KVM early so that the rest of the probing code can use these capabilities to handle KVM/TCG replies differently. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 7 +-

[libvirt] [PATCH v2 15/31] tests: Update capabilities for QEMU 1.3.1

Signed-off-by: Jiri Denemark --- .../qemucapabilitiesdata/caps_1.3.1.x86_64.replies | 88 +- tests/qemucapabilitiesdata/caps_1.3.1.x86_64.xml | 26 ++- 2 files changed, 111 insertions(+), 3 deletions(-) diff --git

Re: [libvirt] Opinions on removing the old, legacy libvirt Xen driver

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote: Hi All, I briefly mentioned this at an evening event during the KVM Forum / Xen Dev Summit, but the list is certainly a better place to discuss such a topic. What do folks think about finally removing the old, legacy, xend-based driver

[libvirt] [PATCH] util: Print pid_t as long long

After commit f2bf5fbb0449, MinGW strikes again. Simply print pid as any other place after commit b7d2d4af2bd5. Signed-off-by: Martin Kletzander --- Notes: Pushed under the 'build breaker' rule. src/util/virprocess.c | 7 --- 1 file changed, 4 insertions(+), 3

Re: [libvirt] [PATCH] NEWS: Start using the improved format

On Fri, Nov 18, 2016 at 05:16:47PM +0100, Andrea Bolognani wrote: This entry is meant to both get the ball rolling on the switch and to provide a blueprint of what NEWS file entries are supposed to look like. --- We need to start somewhere, and what better way than talking about the change

Re: [libvirt] [PATCH 2/4] docs: Upgrade Overpass fonts to 3.0

On Fri, Nov 18, 2016 at 03:28:33PM +, Daniel P. Berrange wrote: On Fri, Nov 18, 2016 at 03:23:55PM +, Daniel P. Berrange wrote: On Fri, Nov 18, 2016 at 04:05:52PM +0100, Martin Kletzander wrote: > Since we are useing Overpass for the web pages, we might be using the s/useing/using/

Re: [libvirt] [PATCH 0/4] docs: User Overpass 3.0 as a font

On Fri, Nov 18, 2016 at 04:26:48PM +0100, Michal Privoznik wrote: On 18.11.2016 16:21, Daniel P. Berrange wrote: On Fri, Nov 18, 2016 at 04:05:50PM +0100, Martin Kletzander wrote: I heard Overpass 3.0 was released, so let's update to that. There are some changes that I noticed. There are