On Fri, May 31, 2019 at 4:31 PM Ilias Stamatis
wrote:
>
> Always return "domain_name" + "host".
>
> Signed-off-by: Ilias Stamatis
> ---
> src/test/test_driver.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
>
This helper converts a set of NUMA node to the set of CPUs
they contain.
Signed-off-by: Andrea Bolognani
---
src/libvirt_private.syms | 1 +
src/util/virnuma.c | 55
src/util/virnuma.h | 2 ++
3 files changed, 58 insertions(+)
diff --git
The original implementation is extremely straightforward but
not too efficient, because it uses the public API instead of
poking the innards directly. This second implementation does
the latter, and as a consequence can afford to make @b const,
which is nice even though most existing virBitmap
Signed-off-by: Andrea Bolognani
---
src/libvirt_private.syms | 1 +
src/util/virbitmap.c | 26 ++
src/util/virbitmap.h | 4
tests/virbitmaptest.c| 37 +
4 files changed, 68 insertions(+)
diff --git
Commit f136b83139c6 made some changes in the way we set CPU
affinity for QEMU processes, and while doing so unfortunately
also introduced a logic bug in that it tried to use a NUMA node
map where a CPU map was expected.
Because of that, guests using would suddenly fail to
start:
# virsh start
See detailed explanation in the commit message for patch 1/4
and the corresponding bug report.
Andrea Bolognani (4):
util: Introduce virBitmapUnion()
fixup? util: Optimize virBitmapUnion()
util: Introduce virNumaNodesetToCPUset()
qemu: Fix qemuProcessInitCpuAffinity()
Always return "domain_name" + "host".
Signed-off-by: Ilias Stamatis
---
src/test/test_driver.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 2f58a1da95..aad7bb6036 100644
--- a/src/test/test_driver.c
+++
On 5/31/19 8:05 AM, Erik Skultety wrote:
One of the current SEV document links went dead as AMD moved the
resource to another place (document store), so there's probably very
little point in maintaining 3rd party links if the resources are being
moved.
Signed-off-by: Erik Skultety
---
On 5/30/19 8:51 PM, Jiri Denemark wrote:
Depending on the way ctags was compiled, it may look for
.ctags.d/*.ctags files rather than .ctags for reading configuration.
Signed-off-by: Jiri Denemark
---
.ctags.d/libvirt.ctags | 1 +
1 file changed, 1 insertion(+)
create mode 12
> -Original Message-
> From: Michal Privoznik [mailto:mpriv...@redhat.com]
> Sent: Friday, May 31, 2019 3:25 PM
> To: wangxin (U) ; libvir-list@redhat.com
> Cc: Lichunhe (Cloud Networking)
> Subject: Re: Question about save and restore OVS per-port data in live
> migration
>
> On
This patch adds a new
element into the host CPU capabilities XML.
Signed-off-by: Jiri Denemark
---
src/conf/cpu_conf.c | 48 +
src/conf/cpu_conf.h | 2 ++
2 files changed, 50 insertions(+)
diff --git a/src/conf/cpu_conf.c
Commit 0a97486e09 moved them outside #ifdef, but after virCPUx86GetHost,
which will start calling them in the following patch.
Signed-off-by: Jiri Denemark
---
src/cpu/cpu_x86.c | 72 +++
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git
When the host CPU supports invariant TSC the host CPU definition created
by virCPUx86GetHost will contain (unless probing fails for some reason)
addition TSC related data.
Signed-off-by: Jiri Denemark
---
src/cpu/cpu_x86.c | 9 +
1 file changed, 9 insertions(+)
diff --git
When migrating a domain with invtsc CPU feature enabled, the TSC
frequency of the destination host must match the frequency used when the
domain was started on the source host or the destination host has to
support TSC scaling.
If the frequencies do not match and the destination host does not
On a KVM x86_64 host which supports invariant TSC this function can be
used to detect the TSC frequency and the availability of TSC scaling.
The magic MSR numbers required to check if VMX scaling is supported on
the host are documented in Volume 3 of the Intel® 64 and IA-32
Architectures Software
When migrating a domain with invtsc CPU feature enabled, the TSC
frequency of the destination host must match the frequency used when the
domain was started on the source host or the destination host has to
support TSC scaling.
If the frequencies do not match and the destination host does not
If libvirt receive DISCONNECTED event and set prDaemonRunning to false,
and qemuDomainRemoveDiskDevice is performing in the meantime.
qemuDomainRemoveDiskDevice will return directly by prDaemonRunning
check, so the pr-helper0 object will remain.
In that case we should try harder and also kill the
On 5/30/19 4:33 PM, Andrea Bolognani wrote:
Hopefully I've done a decent enough job at summarizing, especially
with the security stuff: if not, please let me know!
Andrea Bolognani (2):
news: Reformat overgrown line
news: Update for 5.4.0 release
docs/news.xml | 61
On 5/31/19 10:06 AM, wangjie (P) wrote:
Hi, Michal:
Sorry, I don't think out which case make us to do that, what are
the risks? can you give me an example?
Well, qemuProcessKillManagedPRDaemon() not only kills pr-helper process
but it also cleans up after it. If we receive DISCONNECTED
This is tagged in git, I have put the signed tarball and source RPM at
the usual place:
https://libvirt.org/sources/
this is virtually identical to RC1 except for the portability fix from Jim.
I hope this means it's stable, or everybody is taking days off :-)
likely to push the final
Hi, Michal:
Sorry, I don't think out which case make us to do that, what are
the risks? can you give me an example?
On 2019/5/31 15:21, Michal Privoznik wrote:
On 5/31/19 9:19 AM, wangjie (P) wrote:
Hi, Michal:
Do you mean we should also remove "if (!priv->prDaemonRunning)"
in
On 5/30/19 3:50 AM, wangxin (U) wrote:
-Original Message-
From: Michal Privoznik [mailto:mpriv...@redhat.com]
Sent: Wednesday, May 29, 2019 3:44 PM
To: wangxin (U) ; libvir-list@redhat.com
Cc: Lichunhe (Cloud Networking)
Subject: Re: Question about save and restore OVS per-port data in
On 5/31/19 9:19 AM, wangjie (P) wrote:
Hi, Michal:
Do you mean we should also remove "if (!priv->prDaemonRunning)" in
qemuProcessKillManagedPRDaemon ? I don't understand why do that, can you
tell me more details?
Yes. I mean exactly that.
Michal
--
libvir-list mailing list
Hi, Michal:
Do you mean we should also remove "if (!priv->prDaemonRunning)" in
qemuProcessKillManagedPRDaemon ? I don't understand why do that, can you
tell me more details?
On 2019/5/30 18:22, Michal Privoznik wrote:
On 5/29/19 11:44 AM, Jie Wang wrote:
if libvirt receive DISCONNECTED
One of the current SEV document links went dead as AMD moved the
resource to another place (document store), so there's probably very
little point in maintaining 3rd party links if the resources are being
moved.
Signed-off-by: Erik Skultety
---
docs/formatdomaincaps.html.in | 16
25 matches
Mail list logo
