On Tue, 11 May 2021 13:02:08 +0100
Peter Maydell wrote:
> On Thu, 6 May 2021 at 16:44, Cornelia Huck wrote:
> >
> > The following changes since commit d45a5270d075ea589f0b0ddcf963a5fea1f500ac:
> >
> > Merge remote-tracking branch
> > 'remotes/vivier2/tags/trivial-branch-for-6.1-pull-request'
Hi Zoltan,
On 5/11/21 1:28 PM, BALATON Zoltan wrote:
> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote:
>> The motivation behind this series is to remove the
>> isa_get_irq(NULL) call to simplify the ISA generic model.
>>
>> Since v1:
>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-202
On Fri, 30 Apr 2021 at 21:41, Richard Henderson
wrote:
>
> Exclude PMULL from this category for the moment.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper-sve.h| 15 +++
> target/arm/sve.decode | 9 +
> target/arm/sve_helper.c| 31 +++
On May 11 09:35, Hannes Reinecke wrote:
Ever since commit e570768566 ("hw/block/nvme: support for shared
namespace in subsystem") NVMe PCI hotplug is broken, as the PCI
hotplug infrastructure will only work for the nvme devices (which
are PCI devices), but not for any attached namespaces.
So when
Hi Lukas,
On 5/4/21 5:34 PM, Lukas Jünger wrote:
> Signed-off-by: Lukas Jünger
> ---
> include/hw/char/sifive_uart.h | 6 +--
> hw/char/sifive_uart.c | 72 ++-
> 2 files changed, 65 insertions(+), 13 deletions(-)
> +static void sifive_uart_realize(Device
On 10/05/21 13:28, Vladimir Sementsov-Ogievskiy wrote:
Could we instead add a c file and add the structure private? Then we'll
have progress_new() and progress_free() APIs instead.
This way, it would be a lot simpler to control that nobady use structure
fields directly.
I don't know... I
On Mon, May 10, 2021 at 5:55 PM Greg Kurz wrote:
>
> Honor the expected behavior of syncfs() to synchronously flush all data
> and metadata on linux systems. Simply loop on all known submounts and
> call syncfs() on them.
Why not pass the submount's root to the server, so it can do just one
targe
On Fri, 30 Apr 2021 at 21:34, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu.h | 10 ++
> target/arm/helper-sve.h| 1 +
> target/arm/sve.decode | 2 ++
> target/arm/translate-sve.c | 22 ++
> target/arm/vec_he
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
On Fri, 30 Apr 2021 at 21:41, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper-sve.h| 8 ++
> target/arm/sve.decode | 8 ++
> target/arm/sve_helper.c| 26 ++
> target/arm/translate-sve.c | 159 +
> 4
On Fri, 30 Apr 2021 at 21:35, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper-sve.h| 5 +
> target/arm/sve.decode | 5 +
> target/arm/sve_helper.c| 20
> target/arm/translate-sve.c | 19 +++
> 4 f
Hi Sebastien,
On #virtio-fs IRC you asked:
I have a vhost-user question regarding disconnection/reconnection. How
should this be handled? Let's say the vhost-user backend disconnects,
and reconnects later on, does QEMU reset the virtio device by notifying
the guest? Or does it simply reconnect
Can you still reproduce this with QEMU v6.0 ? For me, qemu now does not
crash anymore, so I assume this might have been fixed within the past
months?
** Changed in: qemu
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which
On Tue, May 11, 2021 at 02:31:14PM +0200, Miklos Szeredi wrote:
> On Mon, May 10, 2021 at 5:55 PM Greg Kurz wrote:
> >
> > Honor the expected behavior of syncfs() to synchronously flush all data
> > and metadata on linux systems. Simply loop on all known submounts and
> > call syncfs() on them.
>
On Fri, 30 Apr 2021 at 21:40, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu.h | 5 +++
> target/arm/helper-sve.h| 15
> target/arm/sve.decode | 6
> target/arm/sve_helper.c| 73 ++
>
On Fri, 30 Apr 2021 at 21:43, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> v2: Fix subtraction ordering (laurent desnogues).
> ---
> target/arm/helper-sve.h| 10 +
> target/arm/sve.decode | 9
> target/arm/sve_helper.c| 42 +
Hi Lukas,
On Wed, May 5, 2021 at 12:49 AM Lukas Jünger
wrote:
>
While we are here, could we make other functions sifive_ prefixed?
Also the commit title should include a tag of "hw/char: sifive_uart"
> Signed-off-by: Lukas Jünger
> ---
> hw/char/sifive_uart.c | 14 +++---
> 1 file ch
On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote:
Hi Zoltan,
On 5/11/21 1:28 PM, BALATON Zoltan wrote:
On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote:
The motivation behind this series is to remove the
isa_get_irq(NULL) call to simplify the ISA generic model.
Since v1:
- rebased on top of
On 5/11/21 2:22 PM, Klaus Jensen wrote:
> On May 11 09:35, Hannes Reinecke wrote:
>> Ever since commit e570768566 ("hw/block/nvme: support for shared
>> namespace in subsystem") NVMe PCI hotplug is broken, as the PCI
>> hotplug infrastructure will only work for the nvme devices (which
>> are PCI de
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.yml | 6 +++---
tests/docker/dockerfiles/centos8.docker | 1 +
2 files ch
The main motivation for this series is to eliminate some backcompat
logic in the crypto code only needed for RHEL-7. I take the opportunity
to also bump the min required versions of glib, gcc and clang since we
have dropped many distros since they were last bumped.
There are possibly some more cle
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.
Signed-off-by: Daniel P. Berrangé
---
.patchew.yml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/.patchew.yml b/.patche
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required gcrypt version and
assume that HMAC is always supported
Per repology, current shipping versions are:
Now that we only support modern nettle, we don't need to have local
typedefs to mask the real nettle types.
Signed-off-by: Daniel P. Berrangé
---
crypto/cipher-nettle.c.inc | 60 --
crypto/hash-nettle.c | 6 ++--
crypto/hmac-nettle.c | 8 ++---
3
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required nettle version and
drop a lot of backwards compatibility code for 2.x series of nettle.
Per repology, cur
The condition being tested has never been set since the day the code was
first introduced.
Signed-off-by: Daniel P. Berrangé
---
crypto/tlscredsx509.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/crypto/tlscredsx509.c b/crypto/tlscredsx509.c
index bc503bab55..d9d6f4421e 100644
--- a/cryp
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.d/containers.yml | 5 ---
tests/docker/dockerfiles/centos7.docker | 43 --
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required gnutls version
Per repology, current shipping versions are:
RHEL-8: 3.6.14
Debian Stre
The glib version was not previously constrained by RHEL-7 since it
rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the
constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of
these are old enough that they are outside our platform support
matrix now.
Per repology, current ship
Signed-off-by: Daniel P. Berrangé
---
tests/vm/centos | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/vm/centos b/tests/vm/centos
index efe3dbbb36..215da14c23 100755
--- a/tests/vm/centos
+++ b/tests/vm/centos
@@ -26,13 +26,13 @@ class CentosVM(basevm.BaseVM):
Several distros have been dropped since the last time we bumped the
minimum required GCC version.
Per repology, currently shipping versions are:
RHEL-8: 8.3.1
Debian Stretch: 6.3.0
Debian Buster: 8.3.0
openSUSE Leap 15.2: 7.5.0
Ubuntu LTS 18.04: 7.5.0
Ubuntu LTS 20.
Several distros have been dropped since the last time we bumped the
minimum required CLang version.
Per repology, currently shipping versions are:
RHEL-8: 10.0.1
Debian Stretch: 7.0.1
Debian Buster: 7.0.1
openSUSE Leap 15.2: 9.0.1
Ubuntu LTS 18.04: 10.0.0
Ubuntu LTS
Hi All,
In the context of vhost-user, I was wondering how a reconnection should
be handled from the VMM perspective?
In particular, I'm looking at the OVS-DPDK use case using the client
mode (meaning QEMU acts as the server), and I'd like to understand what
QEMU does to handle this. Upon discon
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
On May 11 15:12, Hannes Reinecke wrote:
On 5/11/21 2:22 PM, Klaus Jensen wrote:
On May 11 09:35, Hannes Reinecke wrote:
Ever since commit e570768566 ("hw/block/nvme: support for shared
namespace in subsystem") NVMe PCI hotplug is broken, as the PCI
hotplug infrastructure will only work for the
** Tags added: tcg
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1896298
Title:
memory leak
Status in QEMU:
Confirmed
Bug description:
qemu trunk as of today leaks memory FAST when freedos' e
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.yml | 6 +++---
tests/
Richard Henderson writes:
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
Richard Henderson writes:
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
On Tue, May 11, 2021 at 08:48:44AM +0200, Philippe Mathieu-Daudé wrote:
> +Stefan/Peter
>
> On 4/19/21 12:59 PM, Thomas Huth wrote:
> > On 19/04/2021 12.51, Daniel P. Berrangé wrote:
> >> On Mon, Apr 19, 2021 at 12:48:25PM +0200, Thomas Huth wrote:
> >>> On 19/04/2021 12.36, Daniel P. Berrangé wro
Richard Henderson writes:
> At the same time, rename to parts64_silence_nan, split out
> parts_silence_nan_frac, and define a macro for parts_silence_nan.
Reviewed-by: Alex Bennée
--
Alex Bennée
Richard Henderson writes:
> Shuffle the fraction to the end, otherwise sort by size.
> Add frac_hi and frac_lo members to alias frac.
>
> Signed-off-by: Richard Henderson
> ---
> fpu/softfloat.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/fpu/softfl
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.
Signed-off-by: Daniel P. Berrangé
---
.patchew.yml | 6 +++---
1 file changed, 3 insertions(+),
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required nettle version and
drop a lot of backwards compatibility
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
Now that we only support modern nettle, we don't need to have local
typedefs to mask the real nettle types.
Signed-off-by: Daniel P. Berrangé
---
crypto/cipher-nettle.c.inc | 60 --
crypto/hash-nettle.c
Philippe Mathieu-Daudé writes:
> +Stefan/Peter
>
> On 4/19/21 12:59 PM, Thomas Huth wrote:
>> On 19/04/2021 12.51, Daniel P. Berrangé wrote:
>>> On Mon, Apr 19, 2021 at 12:48:25PM +0200, Thomas Huth wrote:
On 19/04/2021 12.36, Daniel P. Berrangé wrote:
> On Mon, Apr 19, 2021 at 12:20:5
[ +qemu-devel ]
On 2021/4/30 22:29, Alex Williamson wrote:
> On Fri, 30 Apr 2021 15:57:47 +0800
> Yicong Yang wrote:
>
>> When I try to remove the PF driver in the host, the process will be blocked
>> if the related VF of the device is added in the Qemu as an iEP.
>>
>> here's what I got in the
On Tue, May 11, 2021 at 03:54:26PM +0200, Thomas Huth wrote:
> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> > It has been over two years since RHEL-8 was released, and thus per the
> > platform build policy, we no longer need to support RHEL-7 as a build
> > target.
> >
> > Signed-off-by: Dani
On Mon, May 03, 2021 at 01:25:44PM +0200, Paolo Bonzini wrote:
> This is a revamp of the qemu_co_sleep* API that makes it easier to
> extend the API: the state that is needed to wake up a coroutine is now
> part of the public API instead of hidden behind a pointer-to-pointer;
> the API is made more
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required gcrypt version and
assume that HMAC is always supported
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required gnutls version
Per repology, current shipping versions a
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
The glib version was not previously constrained by RHEL-7 since it
rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the
constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of
these are old enough that they are outside our platfor
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target.
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.d/containers.yml | 5 ---
tests/do
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
Several distros have been dropped since the last time we bumped the
minimum required GCC version.
Per repology, currently shipping versions are:
RHEL-8: 8.3.1
Debian Stretch: 6.3.0
Debian Buster: 8.3.0
openSUSE Leap 15.
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
Several distros have been dropped since the last time we bumped the
minimum required CLang version.
[...]
-# if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
-# error You need at least Clang v3.4 to compile QEMU
+# if __c
From: Hyman Huang(黄勇)
introduce optional sample-pages argument in calc-dirty-rate,
making sample page count per GB configurable so that more
accurate dirtyrate can be calculated.
Signed-off-by: Hyman Huang(黄勇)
---
migration/dirtyrate.c | 31 +++
migration/dirtyrate.
From: Hyman Huang(黄勇)
This is v3 of introducing sample pages argument to dirty rate interface
v3:
- only add the "6.1" tag to the sample-pages field of DirtyRateInfo
v2:
- do the code clean on the basis of review by David
- add qemu version to 6.1 since which the argument introduced
- raise th
On Tue, May 11, 2021 at 08:48:44AM +0200, Philippe Mathieu-Daudé wrote:
> +Stefan/Peter
>
> Not sure if following up this thread or start a new one, but I got
> blocked again from Gitlab, tagged as a crypto miner for running QEMU
> CI...
> [1]
> https://about.gitlab.com/handbook/support/workflows/
On Tue, May 11, 2021 at 04:15:57PM +0200, Thomas Huth wrote:
> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> > Several distros have been dropped since the last time we bumped the
> > minimum required GCC version.
> >
> > Per repology, currently shipping versions are:
> >
> > RHEL
Daniel P. Berrangé writes:
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
>
> Signed-off-by: Daniel P. Berrangé
Acked-by: Alex Bennée
--
Alex Bennée
On 11/05/2021 15.26, Daniel P. Berrangé wrote:
The main motivation for this series is to eliminate some backcompat
logic in the crypto code only needed for RHEL-7. I take the opportunity
to also bump the min required versions of glib, gcc and clang since we
have dropped many distros since they we
On Tue, May 11, 2021 at 04:18:54PM +0200, Thomas Huth wrote:
> On 11/05/2021 15.26, Daniel P. Berrangé wrote:
> > Several distros have been dropped since the last time we bumped the
> > minimum required CLang version.
> [...]
> > -# if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor_
Alex Bennée writes:
> We special case this as the container with the cross compiler for the
> tests takes so long to build it is manually uploaded into the
> registry.
Gahh, something changed underneath me with the inclusion of:
commit 46ef47e2a77d1a34996964760b4a0d2b19476f25
Author: Tayl
On Tue, May 11, 2021 at 08:54:09AM -0400, Vivek Goyal wrote:
> On Tue, May 11, 2021 at 02:31:14PM +0200, Miklos Szeredi wrote:
> > On Mon, May 10, 2021 at 5:55 PM Greg Kurz wrote:
> > >
> > > Honor the expected behavior of syncfs() to synchronously flush all data
> > > and metadata on linux system
> -Original Message-
> From: Alex Bennée
...
> Which leads to the compiler complaining:
>
> hexagon-unknown-linux-musl-clang -Wno-incompatible-pointer-types -
> Wno-undefined-internal -fno-unroll-loops -Wall -Werror -O0 -g -fno-strict-
> aliasing -mv67 -O2 -static /home
> /alex.benne
On 5/11/21 3:37 PM, Klaus Jensen wrote:
> On May 11 15:12, Hannes Reinecke wrote:
>> On 5/11/21 2:22 PM, Klaus Jensen wrote:
[ .. ]
>>> The hotplug fix looks good - I'll post a series that tries to integrate
>>> both.
>>>
>> Ta.
>>
>> The more I think about it, the more I think we should be looking
Hi Stefan,
Thanks for the explanation.
So reconnection for vhost-user is not a well defined behavior,
and QEMU is doing its best to retry when possible, depending
on each device.
The guest does not know about it, so it's never notified that
the device needs to be reset.
But what about the vhost
On 5/11/21 8:57 AM, Alex Bennée wrote:
+union {
+/* Routines that know the structure may reference the singular name. */
+uint64_t frac;
+/*
+ * Routines expanded with multiple structures reference "hi" and "lo".
+ * In this structure, the one word is b
On Tue, May 11, 2021 at 02:26:37PM +0100, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé
> ---
> tests/vm/centos | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/vm/centos b/tests/vm/centos
> index efe3dbbb36..215da14c23 100755
> --- a/tests/vm/
On Thu, 6 May 2021 at 20:05, Dr. David Alan Gilbert (git)
wrote:
>
> From: "Dr. David Alan Gilbert"
>
> The following changes since commit d90f154867ec0ec22fd719164b88716e8fd48672:
>
> Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210504'
> into staging (2021-05-05 20:29:1
> -Original Message-
> From: Brian Cain
...
> > I suspect the easiest thing to do is to drop the patches again so I
> > don't hold up the rest of testing/next. I can include the initial
> > docker image patch but I won't enable it in configure.sh/gitlab.
>
> Sorry -- I sent along a patch t
On Tue, 11 May 2021 14:31:14 +0200
Miklos Szeredi wrote:
> On Mon, May 10, 2021 at 5:55 PM Greg Kurz wrote:
> >
> > Honor the expected behavior of syncfs() to synchronously flush all data
> > and metadata on linux systems. Simply loop on all known submounts and
> > call syncfs() on them.
>
> Wh
On Tue, May 11, 2021 at 4:49 PM Vivek Goyal wrote:
>
> On Tue, May 11, 2021 at 08:54:09AM -0400, Vivek Goyal wrote:
> > On Tue, May 11, 2021 at 02:31:14PM +0200, Miklos Szeredi wrote:
> > > On Mon, May 10, 2021 at 5:55 PM Greg Kurz wrote:
> > > >
> > > > Honor the expected behavior of syncfs() to
From: David Hildenbrand
Add two new helper functions. This will come in come handy once we want to
handle ram block resizes while postcopy is active.
Note that ram_block_from_stream() will already print proper errors.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: David Hildenbrand
Messag
From: "Dr. David Alan Gilbert"
The following changes since commit e4f3ede95ce813d5705c65e1c0e1c80c70739ebb:
Merge remote-tracking branch 'remotes/kraxel/tags/usb-20210505-pull-request'
into staging (2021-05-10 19:55:06 +0100)
are available in the Git repository at:
git://github.com/dagrh/
From: David Hildenbrand
The bulk stage is kind of weird: migration_bitmap_find_dirty() will
indicate a dirty page, however, ram_save_host_page() will never save it, as
migration_bitmap_clear_dirty() detects that it is not dirty.
We already fill the bitmap in ram_list_init_bitmaps() with ones, ma
From: Kunkun Jiang
Starting from pss->page, ram_save_host_page() will check every page
and send the dirty pages up to the end of the current host page or
the boundary of used_length of the block. If the host page size is
a huge page, the step "check" will take a lot of time.
It will improve perf
From: David Hildenbrand
Ram block notifiers are currently not aware of resizes. To properly
handle resizes during migration, we want to teach ram block notifiers about
resizeable ram.
Introduce the basic infrastructure but keep using max_size in the
existing notifiers. Supply the max_size when a
From: Markus Armbruster
Result @blocked is redundant. Unfortunately, we realized this too
close to the release to risk dropping it, so we deprecated it
instead, in commit e11ce6c06.
Since it was deprecated from the start, we can delete it without
the customary grace period. Do so.
Signed-off-
From: Kunkun Jiang
When the host page is a huge page and something is sent in the
current iteration, migration_rate_limit() should be executed.
If not, it can be omitted.
Signed-off-by: Keqian Zhu
Signed-off-by: Kunkun Jiang
Reviewed-by: David Edmondson
Reviewed-by: Dr. David Alan Gilbert
Me
From: David Hildenbrand
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works on the usable_length of ram blocks and does
not expect this to change at random points in time.
In the case of precopy, the ram block size must not change on the source,
af
From: David Hildenbrand
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works with the usable_length of a ram block and
does not expect this value to change at random points in time.
In the case of postcopy, relying on used_length is racy as soon as
On Tue, May 11, 2021 at 05:08:42PM +0200, Miklos Szeredi wrote:
> On Tue, May 11, 2021 at 4:49 PM Vivek Goyal wrote:
> >
> > On Tue, May 11, 2021 at 08:54:09AM -0400, Vivek Goyal wrote:
> > > On Tue, May 11, 2021 at 02:31:14PM +0200, Miklos Szeredi wrote:
> > > > On Mon, May 10, 2021 at 5:55 PM Gr
From: David Hildenbrand
Factor it out into common code when a new notifier is registered, just
as done with the memory region notifier. This keeps logic about how to
process existing ram blocks at a central place.
Just like when adding a new ram block, we have to register the max_length.
Ram blo
From: David Hildenbrand
In case we grow our RAM after ram_postcopy_incoming_init() (e.g., when
synchronizing the RAM block state with the migration source), the resized
part would not get discarded. Let's perform that when being notified
about a resize while postcopy has been advised, but is not
From: David Hildenbrand
We actually want to print the used_length, against which we check.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: David Hildenbrand
Message-Id: <20210429112708.12291-10-da...@redhat.com>
Signed-off-by: Dr. David Alan Gilbert
---
migration/multifd.c | 2 +-
1 file
From: David Hildenbrand
Let's make add/remove optional. We want to introduce a RAM block
notifier for RAM migration that is only interested in resize events.
Reviewed-by: Peter Xu
Signed-off-by: David Hildenbrand
Message-Id: <20210429112708.12291-4-da...@redhat.com>
Signed-off-by: Dr. David Al
From: David Hildenbrand
We never read or write beyond the used_length of memory blocks when
migrating. Make this clearer by using offset_in_ramblock() consistently.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: David Hildenbrand
Message-Id: <20210429112708.12291-11-da...@redhat.com>
Signe
From: "Dr. David Alan Gilbert"
Accidental use of "true" as a boolean; spotted by coverity
and Peter.
Fixes: b99784ef6c3
Fixes: d795f47466e
Reported-by: Peter Maydell
Reported-by: Coverity (CID 1432373, 1432292, 1432288)
Signed-off-by: Dr. David Alan Gilbert
Message-Id: <20210504100545.112213-1
From: Hyman
Guestperf tool does not cover the multifd-enabled migration
currently, it is worth supporting so that developers can
analysis the migration performance with all kinds of
migration.
To request that multifd is enabled, with 4 channels:
$ ./tests/migration/guestperf.py \
--multifd -
hsch and csch basically have two parts: execute the command,
and perform the halt/clear function. For fully emulated
subchannels, it is pretty clear how it will work: check the
subchannel state, and actually 'perform the halt/clear function'
and set cc 0 if everything looks good.
For passthrough s
From: David Hildenbrand
We want to make use of ram_block_discard_range() in the RAM block resize
callback when growing a RAM block, *before* used_length is changed.
Let's relax the check. As RAM blocks always mmap the whole max_length area,
we cannot corrupt unrelated data.
Reviewed-by: Peter Xu
From: Peter Maydell
Coverity notices that several places in the migration-test code fail
to free memory in error-exit paths. This is pretty unimportant in
test case code, but we can avoid having to manually free the memory
entirely by using g_autofree.
The places where Coverity spotted a leak w
On Fri, 30 Apr 2021 at 21:44, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> v2: Fix select offsetting and argument order (laurent desnogues).
> ---
> target/arm/helper-sve.h| 14 ++
> target/arm/sve.decode | 12 +
> target/arm/sve_helper.c| 23
On Tue, May 11, 2021 at 03:00:05PM +, Boeuf, Sebastien wrote:
> But what about the vhost-user backend initialization? Does
> QEMU go again through initializing memory table, vrings, etc...
> since it can't assume anything from the backend?
Yes, the initial protocol messages are the same after
Creating and destroying QOM objects does not require a fully constructed
machine. Allow running object-add and object-del before machine
initialization has concluded.
Signed-off-by: Paolo Bonzini
---
hmp-commands.hx | 2 ++
qapi/qom.json | 6 --
2 files changed, 6 insertions(+), 2 deletio
Creating and destroying network backend does not require a fully
constructed machine. Allow the related monitor commands to run before
machine initialization has concluded.
Signed-off-by: Paolo Bonzini
---
hmp-commands.hx | 2 ++
qapi/net.json | 6 --
2 files changed, 6 insertions(+), 2 d
Most block device commands do not require a fully constructed machine.
Allow running them before machine initialization has concluded.
Signed-off-by: Paolo Bonzini
---
hmp-commands.hx| 14 +
qapi/block-core.json | 117 +++--
qapi/block-export.js
On Tue, May 11, 2021 at 10:43:57AM +, John Levon wrote:
> On Tue, May 11, 2021 at 11:09:53AM +0100, Stefan Hajnoczi wrote:
> > Fleshing out irqs sounds like a 1.0 milestone to me. It will definitely
> > be necessary but for now this can be dropped.
>
> I could be wrong, and probably am, but I
On 5/11/21 3:43 AM, Peter Maydell wrote:
+#define do_sqshl_d(n, m) \
+ ({ uint32_t discard; do_sqrshl_d(n, m, false, &discard); })
Why pass in &discard rather than just NULL ? (Similarly below.)
sat != NULL means enable saturation.
Discard the results because unlike NEON, there is no archit
201 - 300 of 494 matches
Mail list logo
