On Tue, Mar 05, 2019 at 16:56:43 +0100, Andrea Bolognani wrote:
> On Tue, 2019-03-05 at 15:38 +0100, Gerd Hoffmann wrote:
[...]
> So I agree neither scenario is exactly perfect, but I still think
> adding non-transitional alias devices would overall be more
> user-friendly.
I don't think it
On 3/5/19 4:13 PM, Michal Privoznik wrote:
On 3/5/19 4:17 AM, Lin Ma wrote:
Signed-off-by: Lin Ma
---
tools/virsh-domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 5699018dcc..c8c4db1b2b 100644
---
On 3/2/19 7:20 AM, Jamie Strandboge wrote:
On Fri, 01 Mar 2019, Jim Fehlig wrote:
Commit a3ab6d42 changed the libvirtd profile to a named profile
but neglected to accommodate the change in the qemu profile
ptrace and signal rules. As a result, libvirtd is unable to
signal confined qemu
On 3/5/19 3:17 AM, Daniel P. Berrangé wrote:
On Mon, Mar 04, 2019 at 04:00:01PM -0700, Jim Fehlig wrote:
Xen 4.10 introduced the max_grant_frames xl config setting, which
can be set globally in xl.conf(5) or per-domain in xl.cfg(5).
max_grant_frames specifies the maximum number of grant frames
On 03/05/19 15:38, Michal Privoznik wrote:
> On 2/28/19 10:31 AM, Laszlo Ersek wrote:
>> On 02/27/19 11:04, Michal Privoznik wrote:
>>> The firmware description is a JSON file which follows
>>> specification from qemu.git/docs/interop/firmware.json. The
>>> description file basically says:
On 03/05/19 15:38, Michal Privoznik wrote:
> On 2/28/19 10:42 AM, Laszlo Ersek wrote:
>> On 02/27/19 11:04, Michal Privoznik wrote:
>>> Test firmware description parsing so far.
>>>
>>> Signed-off-by: Michal Privoznik
>>> ---
>>> tests/Makefile.am | 9
>>>
On 03/05/19 15:38, Michal Privoznik wrote:
> On 2/28/19 12:15 PM, Laszlo Ersek wrote:
>> On 02/27/19 11:04, Michal Privoznik wrote:
>>> And finally the last missing piece. This is what puts it all
>>> together.
>>>
>>> At the beginning, qemuFirmwareFillDomain() loads all possible
>>> firmware
On Tue, Mar 05, 2019 at 05:23:04PM +, Mohammed, Karimullah wrote:
> Hi Daniel,
> MKTME supports encryption of memory(NVRAM) for Virtual Machines(hardware
> based encryption). This features uses Linux kernel key ring services, i.e.
> Operations like, allocation and clearing of secret/keys.
Hi Daniel,
MKTME supports encryption of memory(NVRAM) for Virtual Machines(hardware based
encryption). This features uses Linux kernel key ring services, i.e. Operations
like, allocation and clearing of secret/keys. These keys are used in encryption
of memory in Virtual machines. So MKTME
On Tue, 05 Mar 2019, Christian Ehrhardt wrote:
> Further testing with more devices showed that we sometimes have a
> different depth of pci device paths when accessing sysfs for device
> attributes.
>
> But since the access is limited to a set of filenames and read only it
> is safe to use a
On Tue, 05 Mar 2019, Christian Ehrhardt wrote:
> Further testing with different devices showed that we need more rules
> to drive gl backends with nvidia cards. Related denies look like:
>
> apparmor="DENIED" operation="open"
> name="/usr/share/egl/egl_external_platform.d/"
>
virtio-(non-)transitional device models have been introduced
in 5.2.0, not 5.1.0.
Signed-off-by: Andrea Bolognani
---
Pushed as trivial.
docs/formatdomain.html.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index
Hi all.
I download ftp://libvirt.org/libvirt/libvirt-5.1.0.tar.xz and build
rpms with lxc support.
LXC containers can be started, but time to time can't be stopped.
With option --mode initctl containers always stopped, but virsh reported error:
"Container does not provide an initctl pipe"
On Tue, 2019-03-05 at 15:38 +0100, Gerd Hoffmann wrote:
> Hi,
>
> > -device virtio-blk-pci-non-transitional \
> > -device virtio-net-pci-non-transitional \
> > -device virtio-gpu-pci-non-transitional \
> >
> > and you wouldn't have to question why you can use the
> > non-transitional
On Tue, Mar 05, 2019 at 04:07:39PM +0100, Andrea Bolognani wrote:
While the string associated with the enum value is virtio-scsi,
having the string "SCSI" show up twice in the name of the enum
value is unnecessary and needlessly deviates from the by now
It is not needless, it is for
On Tue, Mar 05, 2019 at 04:07:40PM +0100, Andrea Bolognani wrote:
> At the moment, all VirtIO devices support model=virtio except
> for SCSI controllers where model=virtio-scsi must be used
> instead: get rid of this inconsistency by providing an alias
> at the parser level, so that existing code
While the string associated with the enum value is virtio-scsi,
having the string "SCSI" show up twice in the name of the enum
value is unnecessary and needlessly deviates from the by now
well established practice of having
MODEL_(VIRTIO|VIRTIO_TRANSITIONAL|VIRTIO_NON_TRANSITIONAL)
enum values
Patch 2/2 implement a change that was suggested during the
review process for the recent virtio-(non-)transitional work
but was not considered as blocking for getting the code in,
whereas patch 1/2 performs a trivial and hopefully entirely
non-controversial enum member rename.
Andrea Bolognani
At the moment, all VirtIO devices support model=virtio except
for SCSI controllers where model=virtio-scsi must be used
instead: get rid of this inconsistency by providing an alias
at the parser level, so that existing code keeps working but
using the same values across the board is also
On 2/28/19 10:27 AM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
This is going to extend virDomainLoader enum. The reason is that
once loader path is NULL its type makes no sense. However, since
value of zero corresponds to VIR_DOMAIN_LOADER_TYPE_ROM the
following XML would
On 2/28/19 10:31 AM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
The firmware description is a JSON file which follows
specification from qemu.git/docs/interop/firmware.json. The
description file basically says: Firmware file X is {bios|uefi},
supports these targets and
On 2/28/19 10:11 AM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
Move the code that (possibly) generates filename of NVRAM VAR
store into a single function so that it can be re-used later.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c | 26
Hi,
> -device virtio-blk-pci-non-transitional \
> -device virtio-net-pci-non-transitional \
> -device virtio-gpu-pci-non-transitional \
>
> and you wouldn't have to question why you can use the
> non-transitional variant for pretty much everything, except for the
> few cases where you
On 2/28/19 11:21 AM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
Implementation for yet another part of firmware description
specification. This one covers selecting which files to parse.
There are three locations from which description files can be
loaded. In order of
On 2/28/19 10:42 AM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
Test firmware description parsing so far.
Signed-off-by: Michal Privoznik
---
tests/Makefile.am | 9
tests/qemufirmwaredata/40-bios.json| 35 +
On 2/28/19 12:40 PM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
The firmware selection code will enable the feature if needed.
There's no need to require SMM to be enabled in that case.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c | 4 +++-
1 file changed,
On 2/28/19 12:15 PM, Laszlo Ersek wrote:
On 02/27/19 11:04, Michal Privoznik wrote:
And finally the last missing piece. This is what puts it all
together.
At the beginning, qemuFirmwareFillDomain() loads all possible
firmware description files based on algorithm described earlier.
Then it
On Mon, Mar 04, 2019 at 03:02:11PM +0100, Michal Privoznik wrote:
The stateAutoStart callback will go away shortly. Therefore, move
the autostart call into state initialize callback.
Signed-off-by: Michal Privoznik
---
src/bhyve/bhyve_driver.c | 12 ++--
1 file changed, 2 insertions(+),
On Mon, Mar 04, 2019 at 03:02:10PM +0100, Michal Privoznik wrote:
The order in which drivers are registered is important because
their stateInitialize and stateAutoStart callback are called in
that order. Well, stateAutoStart is going away and therefore if
there is some dependency between two
On Mon, Mar 04, 2019 at 03:02:12PM +0100, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1685151
This reverts commit cefb97fb815c81fc882da752f45effd23bcb9b4b.
The stateAutoStart callback will be removed in the next commit.
Therefore move autostarting of domains, networks
On Mon, Mar 04, 2019 at 03:02:13PM +0100, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1685151
This reverts commit e4a969092bda5b3b952963fdf6658895165040b7.
Now that drivers may call virConnectOpen() on secondary drivers,
it doesn't make much sense to have autostart
On Tue, Mar 05, 2019 at 12:35:48 +0100, Ján Tomko wrote:
> On Tue, Mar 05, 2019 at 10:40:31AM +0100, Jiri Denemark wrote:
> >The log message may be useful when debugging why a specific CPU model
> >was selected for a given set of CPUID data.
> >
> >Signed-off-by: Jiri Denemark
> >---
> >
>
Further testing with more devices showed that we sometimes have a
different depth of pci device paths when accessing sysfs for device
attributes.
But since the access is limited to a set of filenames and read only it
is safe to use a wildcard for that.
Related apparmor denies - while we formerly
passthroughLimit is being calculated even if usesVFIO is false.
After that, a if/else conditional is used to check if we're going
to sum it up with baseLimit.
This patch initializes passthroughLimit to zero and always
return memKB = baseLimit + passthroughLimit. The conditional
is then used to
The NVLink2 support in QEMU implements the detection of NVLink2
capable devices by verfying the attributes of the VFIO mem region
QEMU allocates for the NVIDIA GPUs. To properly allocate an
adequate amount of memLock, Libvirt needs this information before
a QEMU instance is even created.
An
Further testing with different devices showed that we need more rules
to drive gl backends with nvidia cards. Related denies look like:
apparmor="DENIED" operation="open"
name="/usr/share/egl/egl_external_platform.d/"
requested_mask="r"
apparmor="DENIED" operation="open"
The NVIDIA V100 GPU has an onboard RAM that is mapped into the
host memory and accessible as normal RAM via an NVLink2 bus. When
passed through in a guest, QEMU puts the NVIDIA RAM window in a
non-contiguous area, above the PCI MMIO area that starts at 32TiB.
This means that the NVIDIA RAM window
There are a lot of documentation in the comments about how
PPC64 handles passthrough VFIO devices to calculate the
memLockLimit. And more will be added with the PPC64 NVLink2
support code.
Let's remove the PPC64 code from qemuDomainGetMemLockLimitBytes
body and put it into a helper function. This
This series includes Libvirt support for a new QEMU feature for
the spapr (PPC64) machine, NVIDIA V100 + P9 passthrough. Refer to
[1] for the version 3 of this feature (same version used as a reference
for this series).
Changes in v3:
- added a new patch (patch 2) that isolates the PPC64
Please describe the change being made in the commit summary, e.g:
conf: initialize variables in virDomainThreadSchedParseHelper
The 'why?' fits better in the body of the commit message.
Jano
On Tue, Mar 05, 2019 at 10:09:23AM +0100, Erik Skultety wrote:
After commits e2087c2 and ec0793de
Sorry to resurrect such an old thread, but I have been wondering...
On Wed, 2018-12-05 at 17:57 -0200, Eduardo Habkost wrote:
[...]
> Changes v1 -> v2:
> * Removed *-0.9 devices. Nobody will want to use them, if
> transitional devices work with legacy drivers
> (Gerd Hoffmann, Michael S.
On Tue, Mar 05, 2019 at 10:40:31AM +0100, Jiri Denemark wrote:
The log message may be useful when debugging why a specific CPU model
was selected for a given set of CPUID data.
Signed-off-by: Jiri Denemark
---
Notes:
Version 2:
- separated from 11/26 cpu_x86: Allow multiple signatures
On Tue, Mar 05, 2019 at 10:40:30AM +0100, Jiri Denemark wrote:
CPU signatures in the cpu_map serve as a hint for CPUID to CPU model
matching algorithm. If the CPU signatures matches any CPU model in the
cpu_map, this model will be the preferred one.
This works out well and solved several
On Tue, Mar 05, 2019 at 10:40:29AM +0100, Jiri Denemark wrote:
In preparation for storing several CPU signatures in a single CPU model,
we need to turn virCPUx86Model's signature into an array of signatures.
The parser still hardcodes the number of signatures to 1, but the
following patch will
On Tue, Mar 05, 2019 at 10:40:28AM +0100, Jiri Denemark wrote:
Introduce a helper for copying CPU signature between two CPU models.
It's not very useful until the way we store signatures is changed in the
next patch.
Signed-off-by: Jiri Denemark
---
Notes:
Version 2:
- separated from
On Tue, Mar 05, 2019 at 10:40:22AM +0100, Jiri Denemark wrote:
Signed-off-by: Jiri Denemark
---
Notes:
Version 2:
- new patch
tests/cputest.c | 1 +
.../x86_64-cpuid-Core-i7-8700-disabled.xml| 6 +
.../x86_64-cpuid-Core-i7-8700-enabled.xml | 8 +
On Mon, Mar 04, 2019 at 04:00:01PM -0700, Jim Fehlig wrote:
> Xen 4.10 introduced the max_grant_frames xl config setting, which
> can be set globally in xl.conf(5) or per-domain in xl.cfg(5).
> max_grant_frames specifies the maximum number of grant frames the
> domain is allowed to have, which in
On Mon, Mar 04, 2019 at 10:44:12PM +, Mohammed, Karimullah wrote:
> Hi Daniel,
>
> Thank you for answering our questions. We will soon send our design
> documentation for a review/discussion for MKTME enablement. This is
> not a complex feature , but in any case we wanted to start off with
>
Hi Daniel,
QEMU/KVM work is in process of completion and would be published soon for the
community approval(somewhere in March). We are working closely with development
team of KVM/QEMU. Meanwhile, we wanted to start the process in Libvirt
community.
We will submit the work status of QEMU/KVM
Hi Daniel,
Thank you for answering our questions. We will soon send our design
documentation for a review/discussion for MKTME enablement. This is not a
complex feature , but in any case we wanted to start off with a design review ,
so that we get approved forehand for what we will be
In preparation for storing several CPU signatures in a single CPU model,
we need to turn virCPUx86Model's signature into an array of signatures.
The parser still hardcodes the number of signatures to 1, but the
following patch will drop this limit.
Signed-off-by: Jiri Denemark
---
Notes:
The family/model numbers are nice for humans or for comparing with
/proc/cpuinfo, but sometimes there's a need to see the CPUID
representation of the signature. Let's add it into a comment for each
signature in out cpu_map XMLs as the conversion is not exactly
straightforward.
Signed-off-by: Jiri
This is a simple wrapper around virQEMUCapsGetHostCPUData usable in
tests for getting qemuMonitorCPUModelInfoPtr from QEMU caps.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/qemu/qemu_capabilities.c | 10 ++
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_SandyBridge-IBRS.xml | 1 +
src/cpu_map/x86_SandyBridge.xml | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/cpu_map/x86_SandyBridge-IBRS.xml
The function exports the functionality of x86DataToSignatureFull and
x86MakeSignature to the test suite.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu/cpu_x86.c| 12
src/cpu/cpu_x86.h| 5 +
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Nehalem-IBRS.xml | 3 +++
src/cpu_map/x86_Nehalem.xml | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/cpu_map/x86_Nehalem-IBRS.xml b/src/cpu_map/x86_Nehalem-IBRS.xml
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Conroe.xml | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/cpu_map/x86_Conroe.xml b/src/cpu_map/x86_Conroe.xml
index 0055e5005a..89fe0ad2cf 100644
---
The code is separated into a new x86ModelParseAncestor function.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu/cpu_x86.c | 65 +++
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git
Introduce a helper for copying CPU signature between two CPU models.
It's not very useful until the way we store signatures is changed in the
next patch.
Signed-off-by: Jiri Denemark
---
Notes:
Version 2:
- separated from 11/26 cpu_x86: Allow multiple signatures for a CPU model
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
tests/cputest.c |1 +
.../x86_64-cpuid-Xeon-E7540-disabled.xml |5 +
.../x86_64-cpuid-Xeon-E7540-enabled.xml |7 +
CPU signatures in the cpu_map serve as a hint for CPUID to CPU model
matching algorithm. If the CPU signatures matches any CPU model in the
cpu_map, this model will be the preferred one.
This works out well and solved several mismatches, but in real world
CPUs which should match a single CPU
Signed-off-by: Jiri Denemark
---
Notes:
Version 2:
- new patch
tests/cputest.c | 1 +
.../x86_64-cpuid-Core-i7-8700-disabled.xml| 6 +
.../x86_64-cpuid-Core-i7-8700-enabled.xml | 8 +
.../x86_64-cpuid-Core-i7-8700-guest.xml | 28 +
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_IvyBridge-IBRS.xml | 1 +
src/cpu_map/x86_IvyBridge.xml | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/cpu_map/x86_IvyBridge-IBRS.xml
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
tests/cputest.c | 1 +
.../x86_64-cpuid-Core-i7-7600U-disabled.xml | 6 +
.../x86_64-cpuid-Core-i7-7600U-enabled.xml| 8 +
The tests/cputestdata/cpu-parse.sh would produce JSON files with QEMU
replies which wouldn't pass syntax-check. Let's fix this by not emitting
an extra new line after reformatting the JSON file.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Penryn.xml | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/cpu_map/x86_Penryn.xml b/src/cpu_map/x86_Penryn.xml
index 41febb2ddf..279bb05570 100644
---
CPU signatures in the cpu_map serve as a hint for CPUID to CPU model
matching algorithm. If the CPU signatures matches any CPU model in the
cpu_map, this model will be the preferred one.
This works out well and solved several mismatches, but in real world
CPUs which should match a single CPU
The code for transforming qemuMonitorCPUModelInfo data from QEMU into
virCPUDefPtr consumable by virCPU* APIs was hidden inside
virQEMUCapsInitCPUModelX86. This patch moves it into a new function to
make it usable in tests.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
tests/cputest.c | 1 +
.../x86_64-cpuid-Xeon-E5-2630-v4-disabled.xml | 7 +
.../x86_64-cpuid-Xeon-E5-2630-v4-enabled.xml | 8 +
This fixes several CPUs which were incorrectly detected as
Skylake-Client.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Broadwell-IBRS.xml| 3 +++
src/cpu_map/x86_Broadwell-noTSX-IBRS.xml | 3
The log message may be useful when debugging why a specific CPU model
was selected for a given set of CPUID data.
Signed-off-by: Jiri Denemark
---
Notes:
Version 2:
- separated from 11/26 cpu_x86: Allow multiple signatures for a CPU model
- signature formatting code moved into a
The code is separated into a new x86ModelParseSignature function.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- move rc variable inside if statement where it was originally
src/cpu/cpu_x86.c | 58 ---
1 file
The code is separated into a new x86ModelParseVendor function.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu/cpu_x86.c | 50 ++-
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git
Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData
actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the
wrapper introduced in the previous commit instead.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Haswell-IBRS.xml | 3 +++
src/cpu_map/x86_Haswell-noTSX-IBRS.xml | 3 +++
src/cpu_map/x86_Haswell-noTSX.xml | 3 +++
src/cpu_map/x86_Haswell.xml| 3 +++
4 files
Having multiple CPU model definitions with the same name could result in
unexpected behavior.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu/cpu_x86.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Skylake-Client-IBRS.xml | 5 +
src/cpu_map/x86_Skylake-Client.xml | 5 +
2 files changed, 10 insertions(+)
diff --git a/src/cpu_map/x86_Skylake-Client-IBRS.xml
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
tests/cputest.c | 1 +
.../x86_64-cpuid-Xeon-E5-2650-disabled.xml| 5 +
.../x86_64-cpuid-Xeon-E5-2650-enabled.xml | 8 +
The signature computation code is not too complicated and it will likely
never change so testing it is not very important. We do it mostly for a
nice side effect of easily accessible signature numbers for all CPU
data files.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
The code is separated into a new x86ModelParseFeatures function.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu/cpu_x86.c | 68 +++
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git
This fixes several CPUs which were incorrectly detected as a different
CPU model.
Signed-off-by: Jiri Denemark
Reviewed-by: Ján Tomko
---
Notes:
Version 2:
- no change
src/cpu_map/x86_Westmere.xml | 2 ++
tests/cputestdata/x86_64-cpuid-Core-i5-650-json.xml
On Fri, Mar 01, 2019 at 04:57:32PM +0100, Andrea Bolognani wrote:
Basically I see no reason not to cover both active and inactive
when possible, because even when the feature is only going to
manifest itself only in one of the two output files, the fact that
it does *not* show up in the other
After commits e2087c2 and ec0793de older GCC started act very smart and
complain about potentially uninitialized variable, which existed prior
to these patches + even if the affected vars were left uninitialized the
function responsible for filling them in would have failed with NULL
being
On 3/5/19 4:17 AM, Lin Ma wrote:
Signed-off-by: Lin Ma
---
tools/virsh-network.c | 17 ++---
tools/virsh-network.h | 8
2 files changed, 22 insertions(+), 3 deletions(-)
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
On 3/5/19 4:17 AM, Lin Ma wrote:
Signed-off-by: Lin Ma
---
tools/virsh-domain.c | 1 +
1 file changed, 1 insertion(+)
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 3/5/19 4:17 AM, Lin Ma wrote:
Signed-off-by: Lin Ma
---
tools/virsh-domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 5699018dcc..c8c4db1b2b 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@
On 3/5/19 4:17 AM, Lin Ma wrote:
Signed-off-by: Lin Ma
---
tools/virsh-completer.c | 27 +++
tools/virsh-completer.h | 4
tools/virsh-network.c | 1 +
3 files changed, 32 insertions(+)
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
On 3/5/19 4:17 AM, Lin Ma wrote:
Lin Ma (4):
virsh: Only return active domain names for detach-device-alias
virsh: Add device name completion for target option of detach-disk
command
virsh-network: Introduce virshNetworkEventCallback to handle network
events
virsh: Add
88 matches
Mail list logo
