On Tue, Jan 12, 2021 at 21:13:54 +0100, Jiri Denemark wrote:
> On Tue, Jan 12, 2021 at 20:21:19 +0100, Igor Mammedov wrote:
> > On Tue, 12 Jan 2021 09:29:50 +0100
> > Michal Privoznik wrote:
[...]
>
> We consume machine types as opaque strings, we don't parse them and thus
> we don't have any o
On 1/12/21 7:30 PM, Laine Stump wrote:
managed='no' on an allows an unprivileged libvirt to use a
pre-created tap/macvtap device that libvirt has permission to
open/read/write, but no permission to modify (i.e. set the MTU or MAC
address). But when the XML had an setting (which
was put there
managed='no' on an allows an unprivileged libvirt to use a
pre-created tap/macvtap device that libvirt has permission to
open/read/write, but no permission to modify (i.e. set the MTU or MAC
address). But when the XML had an setting (which
was put there in order to tell the *guest* OS what MTU to
On Mon, 2021-01-11 at 10:51 +0100, Paolo Bonzini wrote:
> On 11/01/21 10:38, Daniel P. Berrangé wrote:
> > >
> > > The "-machine" options for accelerators are legacy, the "-accel"
> > > options
> > > is a better mechanism. The following are the details:
> > > https://lore.kernel.org/qemu-devel/3aa
On Tue, Jan 12, 2021 at 20:21:19 +0100, Igor Mammedov wrote:
> On Tue, 12 Jan 2021 09:29:50 +0100
> Michal Privoznik wrote:
>
> > In commit v6.9.0-rc1~450 I've adapted libvirt to QEMU's deprecation of
> > -mem-path and -mem-prealloc and switched to memory-backend-* even for
> > system memory. My
On Tue, Jan 12, 2021 at 20:24:44 +0100, Igor Mammedov wrote:
> On Tue, 12 Jan 2021 18:41:38 +
> Daniel P. Berrangé wrote:
>
> > On Tue, Jan 12, 2021 at 07:28:45PM +0100, Peter Krempa wrote:
> > > On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:
> > > > On Tue, 12 Jan 2021 12:35
On Tue, 12 Jan 2021 18:41:38 +
Daniel P. Berrangé wrote:
> On Tue, Jan 12, 2021 at 07:28:45PM +0100, Peter Krempa wrote:
> > On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:
> > > On Tue, 12 Jan 2021 12:35:19 +0100
> > > Peter Krempa wrote:
> > >
> > > > On Tue, Jan 12, 2021
On Tue, 12 Jan 2021 09:29:50 +0100
Michal Privoznik wrote:
> In commit v6.9.0-rc1~450 I've adapted libvirt to QEMU's deprecation of
> -mem-path and -mem-prealloc and switched to memory-backend-* even for
> system memory. My claim was that that's what QEMU does under the hood
> anyway. And indeed
On Tue, Jan 12, 2021 at 19:56:11 +0100, Peter Krempa wrote:
> On Tue, Jan 12, 2021 at 18:47:36 +0100, Andrea Bolognani wrote:
> > Depending on the memballoon model, the corresponding QOM node
> > will have a different type and we need to account for this
> > when searching for it in the QOM tree.
>
On Tue, Jan 12, 2021 at 18:47:36 +0100, Andrea Bolognani wrote:
> Depending on the memballoon model, the corresponding QOM node
> will have a different type and we need to account for this
> when searching for it in the QOM tree.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1911786
> Signed-off
The error message doesn't actually print the filename of the offending
file:
Incorrect line wrapping in %file
Signed-off-by: Peter Krempa
---
scripts/test-wrap-argv.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/test-wrap-argv.py b/scripts/test-wrap-argv.py
On Wed, Jan 13, 2021 at 01:06:36 +0800, huang...@chinatelecom.cn wrote:
> From: Hyman
>
> The "-machine" options for accelerators are legacy, the "-accel" options
> is a better mechanism. The following are the details:
> https://lore.kernel.org/qemu-devel/3aa73987-40e8-3619-0723-9f17f7385...@redh
On Tue, Jan 12, 2021 at 07:28:45PM +0100, Peter Krempa wrote:
> On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:
> > On Tue, 12 Jan 2021 12:35:19 +0100
> > Peter Krempa wrote:
> >
> > > On Tue, Jan 12, 2021 at 12:29:58 +0100, Michal Privoznik wrote:
> > > > On 1/12/21 12:19 PM, Peter
On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:
> On Tue, 12 Jan 2021 12:35:19 +0100
> Peter Krempa wrote:
>
> > On Tue, Jan 12, 2021 at 12:29:58 +0100, Michal Privoznik wrote:
> > > On 1/12/21 12:19 PM, Peter Krempa wrote:
> > > > On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Pri
On Tue, 12 Jan 2021 12:35:19 +0100
Peter Krempa wrote:
> On Tue, Jan 12, 2021 at 12:29:58 +0100, Michal Privoznik wrote:
> > On 1/12/21 12:19 PM, Peter Krempa wrote:
> > > On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Privoznik wrote:
> > > > This capability tracks whether memory-backend-fil
On 1/12/21 2:47 PM, Andrea Bolognani wrote:
Depending on the memballoon model, the corresponding QOM node
will have a different type and we need to account for this
when searching for it in the QOM tree.
https://bugzilla.redhat.com/show_bug.cgi?id=1911786
Signed-off-by: Andrea Bolognani
---
Depending on the memballoon model, the corresponding QOM node
will have a different type and we need to account for this
when searching for it in the QOM tree.
https://bugzilla.redhat.com/show_bug.cgi?id=1911786
Signed-off-by: Andrea Bolognani
---
src/qemu/qemu_monitor.c | 22 +++
On Wed, 2021-01-06 at 12:04 -0300, Daniel Henrique Barboza wrote:
> * **Bug fixes**
>
> + * Avoid taking extra host memory when launching pSeries guests
> +
> +Under certain conditions, pSeries guests were being launched with more
> +RAM than it was specified in the domain XML by the us
From: Hyman
QEMU introduced a dirty ring feature, this patch add a new
KVM feature 'dirty-ring' to set this feature for kvm guests.
To enable the feature, libvirt add "-accel dirty-gfn-count=xxx"
to QEMU command line, the following XML needs to be added to
the guest's domain description:
From: Hyman
The "-machine" options for accelerators are legacy, the "-accel" options
is a better mechanism. The following are the details:
https://lore.kernel.org/qemu-devel/3aa73987-40e8-3619-0723-9f17f7385...@redhat.com/
This patch introduce QEMU_CAPS_ACCEL capability to tell if we're dealing
From: Hyman
The v3 of Dirty Ring do some modification based on the following discussion:
https://www.redhat.com/archives/libvir-list/2021-January/msg00531.html
https://www.redhat.com/archives/libvir-list/2021-January/msg00520.html
modification 1: introducing the QEMU_CAPS_ACCEL so that we can us
On Tue, Jan 12, 2021 at 04:34:18PM +0100, Andrea Bolognani wrote:
> On Tue, 2021-01-12 at 12:18 -0300, Daniel Henrique Barboza wrote:
> > On 1/12/21 10:24 AM, Andrea Bolognani wrote:
> > > On Mon, 2021-01-11 at 23:03 -0300, Daniel Henrique Barboza wrote:
> > > > On 1/11/21 2:56 PM, Andrea Bolognani
On Tue, 2021-01-12 at 12:18 -0300, Daniel Henrique Barboza wrote:
> On 1/12/21 10:24 AM, Andrea Bolognani wrote:
> > On Mon, 2021-01-11 at 23:03 -0300, Daniel Henrique Barboza wrote:
> > > On 1/11/21 2:56 PM, Andrea Bolognani wrote:
> > > > Daniel, did you test migration between libvirt 7.0.0 and e
On 1/12/21 10:24 AM, Andrea Bolognani wrote:
On Mon, 2021-01-11 at 23:03 -0300, Daniel Henrique Barboza wrote:
On 1/11/21 2:56 PM, Andrea Bolognani wrote:
Daniel, did you test migration between libvirt 7.0.0 and earlier
releases? Can you confirm it works?
Just tested a migration scenario b
On Mon, 2021-01-11 at 23:03 -0300, Daniel Henrique Barboza wrote:
> On 1/11/21 2:56 PM, Andrea Bolognani wrote:
> > Daniel, did you test migration between libvirt 7.0.0 and earlier
> > releases? Can you confirm it works?
>
> Just tested a migration scenario between 2 hosts (a Power 9 Boston runnin
On 1/12/21 11:09 AM, Andrea Bolognani wrote:
On Tue, 2021-01-12 at 09:17 +0100, Shalini Chellathurai Saroja wrote:
On 1/4/21 9:44 AM, Andrea Bolognani wrote:
On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote:
On 12/17/20 12:19 PM, Andrea Bolognani wrote:
On Wed, 2020-12-1
On 1/12/21 12:35 PM, Peter Krempa wrote:
On Tue, Jan 12, 2021 at 12:29:58 +0100, Michal Privoznik wrote:
On 1/12/21 12:19 PM, Peter Krempa wrote:
On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Privoznik wrote:
This capability tracks whether memory-backend-file has
"x-use-canonical-path-for-ram
On Tue, Jan 12, 2021 at 12:29:58 +0100, Michal Privoznik wrote:
> On 1/12/21 12:19 PM, Peter Krempa wrote:
> > On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Privoznik wrote:
> > > This capability tracks whether memory-backend-file has
> > > "x-use-canonical-path-for-ramblock-id" attribute. Introdu
On 1/12/21 12:19 PM, Peter Krempa wrote:
On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Privoznik wrote:
This capability tracks whether memory-backend-file has
"x-use-canonical-path-for-ramblock-id" attribute. Introduced into
QEMU by commit v4.0.0-rc0~189^2. While "x-" prefix is considered
Ple
On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Privoznik wrote:
> This capability tracks whether memory-backend-file has
> "x-use-canonical-path-for-ramblock-id" attribute. Introduced into
> QEMU by commit v4.0.0-rc0~189^2. While "x-" prefix is considered
Please use a commit hash instead of this.
On Tue, 2021-01-12 at 09:17 +0100, Shalini Chellathurai Saroja wrote:
> On 1/4/21 9:44 AM, Andrea Bolognani wrote:
> > On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote:
> > > On 12/17/20 12:19 PM, Andrea Bolognani wrote:
> > > > On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellat
Hi, all,
I wound like to thank you all for reviewing the code so promptly.
As discussed earlier. The following conclusions can be drawn :
1. This unfortunately cannot be done unconditionally. You need to
probe for the availability of -accel.
---
This capability tracks whether memory-backend-file has
"x-use-canonical-path-for-ramblock-id" attribute. Introduced into
QEMU by commit v4.0.0-rc0~189^2. While "x-" prefix is considered
experimental or internal to QEMU, the next commit justifies its
use.
Signed-off-by: Michal Privoznik
---
src/q
Patch 2/2 is where the actual logic is happening. It is also depending
on the following QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01979.html
Once merged I'll replace those two occurrences of 'QEMU commit XXX' with
proper commit hash.
Michal Prívozník (2):
qemu_cap
In commit v6.9.0-rc1~450 I've adapted libvirt to QEMU's deprecation of
-mem-path and -mem-prealloc and switched to memory-backend-* even for
system memory. My claim was that that's what QEMU does under the hood
anyway. And indeed it was: see QEMU commit v5.0.0-rc0~75^2~1^2~76 and
look at function c
On 1/4/21 9:44 AM, Andrea Bolognani wrote:
On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote:
On 12/17/20 12:19 PM, Andrea Bolognani wrote:
On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote:
+++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml
@@ -0,0 +
36 matches
Mail list logo
