On Mon, Apr 30, 2018 at 11:10:50AM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 18, 2018 at 05:02:38PM +0800, Peter Xu wrote:
> > diff --git a/monitor.c b/monitor.c
> > index c93aa4e22b..f4951cafbc 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -306,16 +306,20 @@ void monitor_read_command(Mon
On Mon, Apr 30, 2018 at 11:21:26AM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 18, 2018 at 05:02:39PM +0800, Peter Xu wrote:
> > Similar to previous patch, but introduce a new global big lock for
> > mon_fdsets. Take it where needed.
>
> Looks like monitor_fdset_get_fd() is missing.
Yes. Fixing
Peter Maydell writes:
> On 27 April 2018 at 17:17, Thomas Huth wrote:
>> On 27.04.2018 17:51, Peter Maydell wrote:
>>> Hi; I usually let people forget about releases for a month or
>>> so before bringing this topic up, but:
>>>
>>> (1) do we want to call the next release 2.13, or something else?
On Tue, 05/01 22:41, Samuel Thibault wrote:
> Hello,
>
> I'm sorry I didn't find the time to have a look at it before.
>
> In general it looks good, just a few things:
>
> Samuel
>
> Fam Zheng, le ven. 16 mars 2018 14:28:21 +0800, a ecrit:
> > +if (!net_hub_id_for_client(&s->nc, &vlan))
Signed-off-by: Fam Zheng
Reviewed-by: Eric Blake
---
tests/vm/basevm.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
index 3a2d508c35..dcfa6597ad 100755
--- a/tests/vm/basevm.py
+++ b/tests/vm/basevm.py
@@ -101,7 +101,
v4: vlan -> hub. [Samuel]
Free 'info. [Samuel]
v3: - Add Eric's rev-by to patch 2.
- Address Eric's comments on patch 1:
* Fix spell/grammar: "programmed", "awaiting".
* Fix include "qapi/qapi-commands-net.h".
* Underscores to dashes.
* "Since 2.13" now.
v2: Fix co
HMP "info usernet" has been available but it isn't ideal for programmed
use cases. This closes the gap in QMP by adding a counterpart
"query-usernet" command. It is basically translated from
the HMP slirp_connection_info() loop, which now calls the QMP
implementation and prints the data, just like
Vitaly Kuznetsov writes:
> Changes since v4:
> - Rebase on top of Roman's patches.
> - Drop PATCH2 as it is no longer needed (after adding explicit
> hv_frequencies).
>
> Previously, Ladi was working on enabling TSC page clocksource for nested
> Hyper-V-on-KVM workloads. He found out that if Hy
On Mon, 30 Apr 2018 19:36:40 +0200
Thomas Huth wrote:
> On 30.04.2018 13:21, Cornelia Huck wrote:
> > On Mon, 30 Apr 2018 11:33:12 +0100
> > Daniel P. Berrangé wrote:
> [...]
> >> Given, that we have a clear deprecation process now, my view is that
> >> we should formally declare that major ve
>>
>> +static XiveNVT *spapr_xive_get_nvt(XiveFabric *xf, uint32_t server)
>> +{
>> +PowerPCCPU *cpu = spapr_find_cpu(server);
>> +
>> +return cpu ? XIVE_NVT(cpu->intc) : NULL;
>> +}
>
> So this is a bit of a tangent, but I've been thinking of implementing
> a scheme where there's an opa
On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@redhat.com) wrote:
> > > >> a) Bump major version once a year, so we'll have 3.0, 3.1,
> 3.3,
> > >> 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this
> > >> year, so we would only have 3.0 and 3.1 this year.
> > >>
> > >> b) Bump major re
Hi,
> > If we bump the major version each year anyway, why not go the whole way
> > and use 2018.1, 2018.2, ... (or even .)? The nice thing
> > about that is that you can see at a glance when the release took place.
>
> ... or simply drop the first two digits and call them 18.1, 18.2, ...?
We
v3:
- add comment for fields that are protected by monitor lock [Stefan]
- drop most of patch 2, only keep the protections for mon->fds [Stefan]
- add one trivial patch to add some more comments for either readline
and cpu_get/cpu_set [Stefan]
- add protection for monitor_fdset_get_fd() [Stefan]
On 02.05.2018 09:29, Fam Zheng wrote:
> On Tue, 05/01 22:41, Samuel Thibault wrote:
>> Hello,
>>
>> I'm sorry I didn't find the time to have a look at it before.
>>
>> In general it looks good, just a few things:
>>
>> Samuel
>>
>> Fam Zheng, le ven. 16 mars 2018 14:28:21 +0800, a ecrit:
>>> +
The out_lock was only protecting a few Monitor fields. In the future
the monitor code will start to run in multiple threads. We turn it into
a bigger lock to protect not only the out buffer but also all the rest.
For now we share the lock. We can split the lock when needed.
Since at it, arrange
Add some explicit comment for both Readline and cpu_set/cpu_get helpers
that they do not need the mon_lock protection.
Signed-off-by: Peter Xu
---
monitor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 176d3ecc04..38c50e06fc 100644
--- a/moni
mon->fds were protected by BQL. Now protect it by mon_lock so that it
can even be used in monitor iothread.
Signed-off-by: Peter Xu
---
monitor.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 48882d28ae..176d3ecc04 100644
--- a/monit
Similar to previous patch, but introduce a new global big lock for
mon_fdsets. Take it where needed.
Signed-off-by: Peter Xu
---
monitor.c | 64 ---
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/monitor.c b/monitor.c
Fam Zheng, le mer. 02 mai 2018 15:29:36 +0800, a ecrit:
> On Tue, 05/01 22:41, Samuel Thibault wrote:
> > I'm sorry I didn't find the time to have a look at it before.
> >
> > In general it looks good, just a few things:
> >
> > Samuel
> >
> > Fam Zheng, le ven. 16 mars 2018 14:28:21 +0800, a ec
Laszlo Ersek writes:
> We'll soon need an enumeration type that lists all the softmmu targets
> that QEMU (the project) supports. Introduce @SysEmuTarget to
> "common.json".
>
> The enum constant @x86_64 doesn't match the QAPI convention of preferring
> hyphen ("-") over underscore ("_"). This is
Laszlo Ersek writes:
> The TARGET_BASE_ARCH values from "configure" don't all map to the
> @CpuInfoArch enum constants; in particular "s390x" from the former does
> not match @s390 in the latter. Clients are known to rely on the @s390
> constant specifically, so we can't change it silently. Inste
Laszlo Ersek writes:
> Add a new field @target (of type @SysEmuTarget) to the output of the
> @query-cpus-fast command, which provides more information about the
> emulation target than the field @arch (of type @CpuInfoArch). Make @target
> the new discriminator for the @CpuInfoFast return struct
On Wed, May 02, 2018 at 12:43:10AM -0700, Liviu Ionescu wrote:
> On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@redhat.com) wrote:
>
> > > > >> a) Bump major version once a year, so we'll have 3.0, 3.1,
> > 3.3,
> > > >> 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this
> > > >> year,
On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > If we bump the major version each year anyway, why not go the whole way
> > > and use 2018.1, 2018.2, ... (or even .)? The nice thing
> > > about that is that you can see at a glance when the release took place.
> >
>
On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote:
> Our deprecation policy lets us include incompatible
> changes in *any* release.
can you elaborate on this?
where is this policy defined?
thank you,
Liviu
On 02.05.2018 10:02, Liviu Ionescu wrote:
> On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
>> Our deprecation policy lets us include incompatible
>> changes in *any* release.
>
> can you elaborate on this?
>
> where is this policy defined?
https://qemu.weilnetz.de/
On Wed, May 02, 2018 at 09:29:39AM +0200, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On 27 April 2018 at 17:17, Thomas Huth wrote:
> >> On 27.04.2018 17:51, Peter Maydell wrote:
> >>> Hi; I usually let people forget about releases for a month or
> >>> so before bringing this topic up
On 02.05.2018 09:45, Samuel Thibault wrote:
> Fam Zheng, le mer. 02 mai 2018 15:29:36 +0800, a ecrit:
>> On Tue, 05/01 22:41, Samuel Thibault wrote:
>>> I'm sorry I didn't find the time to have a look at it before.
>>>
>>> In general it looks good, just a few things:
>>>
>>> Samuel
>>>
>>> Fam Zhen
On 04/26/2018 11:28 AM, Thomas Huth wrote:
> Note: I've decided to removed the pxelinux.cfg patches from this series
> for now, since full pxelinux support requires to parse some additional
> DHCP options (see https://tools.ietf.org/html/rfc5071), and for this, the
> SLOF libnet code needs to be
On 04/27/2018 03:14 PM, David Hildenbrand wrote:
> On 26.04.2018 11:28, Thomas Huth wrote:
>> Note: I've decided to removed the pxelinux.cfg patches from this series
>> for now, since full pxelinux support requires to parse some additional
>> DHCP options (see https://tools.ietf.org/html/rfc5071)
On Wed, 2 May 2018 01:02:49 -0700
Liviu Ionescu wrote:
> On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > Our deprecation policy lets us include incompatible
> > changes in *any* release.
>
> can you elaborate on this?
>
> where is this policy defined?
See ht
Applied to qapi-next.
Applied PATCH 1-4/5 to qapi-next. I haven't reviewed PATCH 5/5, yet.
Applied to qapi-next, thanks!
On 30 April 2018 at 14:03, Laurent Vivier wrote:
> Le 30/04/2018 à 11:46, Peter Maydell a écrit :
>> On 30 April 2018 at 10:28, Laurent Vivier wrote:
>>> Le 30/04/2018 à 11:12, Peter Maydell a écrit :
Great. Riku/Laurent -- I'm assuming you're going to take this set
via the linux-user t
On 05/02/18 10:31, Markus Armbruster wrote:
> Applied to qapi-next, thanks!
>
\o/
Thank you all for working with me through this! :)
Laszlo
On 2/5/18 4:37 pm, David Gibson wrote:
> On Wed, May 02, 2018 at 02:45:57PM +1000, Alexey Kardashevskiy wrote:
>> At the moment the PPC64/pseries guest only supports 4K/64K/16M IOMMU
>> pages and POWER8 CPU supports the exact same set of page size so
>> so far things worked fine.
>>
>> However POWE
I attached a ZIP file containing a set of binary images that reproduces
the problem.
Secure.elf and NonSecure.elf contain codes that run in the Secure/Non-
Secure mode, respectively. They must be loaded simultaneously by using
the generic loader:
$ qemu-system-arm -device loader,file=Secure.e
On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote:
> https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
Thank you, Thomas.
> It took quite a while to get a consensus on that policy, so I don't
> think that we want to sacrifice that for semver.
ok, this might be a point
On Wed, May 02, 2018 at 02:03:14AM -0700, Liviu Ionescu wrote:
> On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote:
>
> > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
>
> Thank you, Thomas.
>
> > It took quite a while to get a consensus on that policy, so I don't
On Wed, 05/02 09:44, Thomas Huth wrote:
> On 02.05.2018 09:29, Fam Zheng wrote:
> > On Tue, 05/01 22:41, Samuel Thibault wrote:
> >> Hello,
> >>
> >> I'm sorry I didn't find the time to have a look at it before.
> >>
> >> In general it looks good, just a few things:
> >>
> >> Samuel
> >>
> >> Fam Z
On 02/05/2018 08:34, Markus Armbruster wrote:
> Alexey Kardashevskiy writes:
>
>> On 30/4/18 7:39 pm, Paolo Bonzini wrote:
>>> On 30/04/2018 08:52, Alexey Kardashevskiy wrote:
diff --git a/qapi/misc.json b/qapi/misc.json
index 5636f4a..399ec74 100644
--- a/qapi/misc.json
+++ b
On Wed, 2 May 2018 02:03:14 -0700
Liviu Ionescu wrote:
> On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote:
>
> > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
>
> Thank you, Thomas.
>
> > It took quite a while to get a consensus on that policy, so I don't
> >
On 02.05.2018 11:03, Liviu Ionescu wrote:
> On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote:
>
>> https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
>
> Thank you, Thomas.
>
>> It took quite a while to get a consensus on that policy, so I don't
>> think that we want t
On 01/05/2018 10:59, Peter Maydell wrote:
> As well as the SMMU, I'm also thinking about using the IOMMU
> infrastructure for the v8M Memory Protection Controller
> (though that is a bit trickier as I also need it to support
> TCG execution in an IOMMU-controlled region, which is an
> orthogonal bi
Hi Phil,
On 05/02/2018 02:41 AM, Philippe Mathieu-Daudé wrote:
> Hi Bastian,
>
> On 05/01/2018 11:22 AM, Bastian Koppelmann wrote:
>> this includes the Makefile and linker script to build all the tests.
>>
>> Signed-off-by: Bastian Koppelmann
>> ---
>> tests/tcg/tricore/Makefile | 30 ++
On 2/5/18 7:11 pm, Paolo Bonzini wrote:
> On 02/05/2018 08:34, Markus Armbruster wrote:
>> Alexey Kardashevskiy writes:
>>
>>> On 30/4/18 7:39 pm, Paolo Bonzini wrote:
On 30/04/2018 08:52, Alexey Kardashevskiy wrote:
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 5636f4a..399e
Laszlo Ersek writes:
> On 05/02/18 10:31, Markus Armbruster wrote:
>> Applied to qapi-next, thanks!
>>
>
> \o/
>
> Thank you all for working with me through this! :)
Thank *you* for going the extra mile!
On 05/01/2018 06:48 PM, Bastian Koppelmann wrote:
> Hi Alex,
>
> On 05/01/2018 05:40 PM, Alex Bennée wrote:
>> Bastian Koppelmann writes:
>>
>>> this includes the Makefile and linker script to build all the tests.
>>>
>>> Signed-off-by: Bastian Koppelmann
>>> ---
>>> tests/tcg/tricore/Makefile
Paolo Bonzini writes:
> On 02/05/2018 08:34, Markus Armbruster wrote:
>> Alexey Kardashevskiy writes:
>>
>>> On 30/4/18 7:39 pm, Paolo Bonzini wrote:
On 30/04/2018 08:52, Alexey Kardashevskiy wrote:
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 5636f4a..399ec74 100644
On Wed, 2 May 2018 09:16:32 +0100
Daniel P. Berrangé wrote:
> On Wed, May 02, 2018 at 09:29:39AM +0200, Markus Armbruster wrote:
> > How can I provide both the old command line in all its quirky glory and
> > a QAPIfied command line? Unless we can, the deprecation policy doesn't
> > help one bi
Richard Henderson writes:
> The (size > 3 && !is_q) condition is identical to the preceeding test
> of bit 3 in immh; eliminate it. For the benefit of Coverity, assert
> that size is within the bounds we expect.
>
> Fixes: Coverity CID1385846
> Fixes: Coverity CID1385849
> Fixes: Coverity CID13
Richard Henderson writes:
> Path analysis shows that size == 3 && !is_q has been eliminated.
>
> Fixes: Coverity CID1385853
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> target/arm/translate-a64.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --
On 02/05/2018 11:38, Markus Armbruster wrote:
It probably is not unless someone adds properties in realize() callback,
>>> Now work that into the doc comment, please :)
>> Are there any examples?
> There must be examples where instances of the same type have different
> properties, or else our
On 02/05/2018 11:33, Alexey Kardashevskiy wrote:
>> +# Note: the handler creates an object, enumerates properties and
>> destroys
>> +# the object so it only lists properties created in
>> TypeInfo::instance_init().
>> +# Since the instance_init() callback of the device object
On 05/02/2018 11:26 AM, Bastian Koppelmann wrote:
> Hi Phil,
>
[...]
>> I then get:
>>
>> tricore-softmmu/qemu-system-tricore -M tricore_testboard -nographic
>> -kests/tcg/tricore/test_muls.tst -d in_asm
>> QEMU 2.12.50 monitor - type 'help' for more information
>> (qemu) QEMU 2.12.50 monitor - ty
On Wed, May 02, 2018 at 03:44:19PM +0800, Peter Xu wrote:
> mon->fds were protected by BQL. Now protect it by mon_lock so that it
> can even be used in monitor iothread.
>
> Signed-off-by: Peter Xu
> ---
> monitor.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff -
Hi Gerd,
Sorry I didn't had time to try that yet.
I'll try today!
Thanks,
Fred
On 04/25/2018 03:05 PM, Gerd Hoffmann wrote:
On Mon, Apr 23, 2018 at 11:31:34AM +0200, KONRAD Frederic wrote:
On 04/19/2018 03:10 PM, Gerd Hoffmann wrote:
If some event caused some larger playback hickup the fi
The out_lock was only protecting a few Monitor fields. In the future
the monitor code will start to run in multiple threads. We turn it into
a bigger lock to protect not only the out buffer but also all the rest.
For now we share the lock. We can split the lock when needed.
Since at it, arrange
v4:
- fix a s/cur_mon/mon/ typo
v3:
- add comment for fields that are protected by monitor lock [Stefan]
- drop most of patch 2, only keep the protections for mon->fds [Stefan]
- add one trivial patch to add some more comments for either readline
and cpu_get/cpu_set [Stefan]
- add protection for
Similar to previous patch, but introduce a new global big lock for
mon_fdsets. Take it where needed.
Signed-off-by: Peter Xu
---
monitor.c | 64 ---
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/monitor.c b/monitor.c
mon->fds were protected by BQL. Now protect it by mon_lock so that it
can even be used in monitor iothread.
Signed-off-by: Peter Xu
---
monitor.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 48882d28ae..9f361ec21e 100644
--- a/monit
Add some explicit comment for both Readline and cpu_set/cpu_get helpers
that they do not need the mon_lock protection.
Signed-off-by: Peter Xu
---
monitor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 9f361ec21e..6100ad44f8 100644
--- a/moni
On Thu, Apr 19, 2018 at 07:14:39PM +0800, Tiwei Bie wrote:
> On Wed, Apr 18, 2018 at 07:34:06PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Apr 12, 2018 at 11:12:32PM +0800, Tiwei Bie wrote:
> > > This patch introduces VHOST_USER_PROTOCOL_F_HOST_NOTIFIER.
> > > With this feature negotiated, vhost-
On 04/29/18 16:56, Richard Henderson wrote:
> On 04/27/2018 02:01 PM, Michal Suchánek wrote:
>> Is there any reason why the 64bit emulator would not run on 32bit
>> system? The emulated 64bit system is .. emulated after all.
>
> It does run, but it requires that the 32-bit host perform double-word
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
Looking through old bug tickets... can you still reproduce this issue
with the latest (64-bit) version of QEMU? Or could we close this ticket
nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Introducing a new state "postcopy-paused", which can be used when the
postcopy migration is paused. It is targeted for postcopy network
failure recovery.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
qapi/migration.json | 5 -
migration/migration.c | 2 ++
2 files change
Allows the fault thread to stop handling page faults temporarily. When
network failure happened (and if we expect a recovery afterwards), we
should not allow the fault thread to continue sending things to source,
instead, it should halt for a while until the connection is rebuilt.
When the dest ma
The old incoming migration is running in main thread and default
gcontext. With the new qio_channel_add_watch_full() we can now let it
run in the thread's own gcontext (if there is one).
Currently this patch does nothing alone. But when any of the incoming
migration is run in another iothread (e
Tree is pushed here for better reference and testing:
https://github.com/xzpeter/qemu/tree/postcopy-recovery-support
Note that now OOB is still off by default; we need this extra line
applied to the old test scripts to allow OOB to work (instead of "-qmp
stdio"):
-chardev stdio,id=char0 -mon
When there is IO error on the incoming channel (e.g., network down),
instead of bailing out immediately, we allow the dst vm to switch to the
new POSTCOPY_PAUSE state. Currently it is still simple - it waits the
new semaphore, until someone poke it for another attempt.
One note is that here on ram
It will be used when we want to resume one paused migration.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
qapi/migration.json | 5 -
hmp.c | 4 +++-
migration/migration.c | 2 +-
hmp-commands.hx | 7 ---
4 files changed, 12 insertions(+), 6 del
Introducing new migration state "postcopy-recover". If a migration
procedure is paused and the connection is rebuilt afterward
successfully, we'll switch the source VM state from "postcopy-paused" to
the new state "postcopy-recover", then we'll do the resume logic in the
migration thread (along wit
Now when network down for postcopy, the source side will not fail the
migration. Instead we convert the status into this new paused state, and
we will try to wait for a rescue in the future.
If a recovery is detected, migration_thread() will reset its local
variables to prepare for that.
Reviewed
Let the thread pause for network issues.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
migration/migration.h | 1 +
migration/migration.c | 35 +--
migration/trace-events | 2 ++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git
This patch implements the first part of core RAM resume logic for
postcopy. ram_resume_prepare() is provided for the work.
When the migration is interrupted by network failure, the dirty bitmap
on the source side will be meaningless, because even the dirty bit is
cleared, it is still possible that
Introducing this new command to be sent when the source VM is ready to
resume the paused migration. What the destination does here is
basically release the fault thread to continue service page faults.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
migration/savevm.h | 1
On the destination side, we cannot wake up all the threads when we got
reconnected. The first thing to do is to wake up the main load thread,
so that we can continue to receive valid messages from source again and
reply when needed.
At this point, we switch the destination VM state from postcopy-p
This patch detects the "resume" flag of migration command, rebuild the
channels only if the flag is set.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
migration/migration.c | 91 +++
1 file changed, 70 insertions(+), 21 deletions
Though we may not need it, now we init both the src/dst migration
objects in migration_object_init() so that even incoming migration
object would be thread safe (it was not).
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
migration/migration.c | 37 +++--
Add a new vm command MIG_CMD_RECV_BITMAP to request received bitmap for
one ramblock.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
migration/savevm.h | 1 +
migration/savevm.c | 61 ++
migration/trace-events | 2 ++
3
It pauses an ongoing migration. Currently it only supports postcopy.
Note that this command will work on either side of the migration.
Basically when we trigger this on one side, it'll interrupt the other
side as well since the other side will get notified on the disconnect
event.
However, it's s
Creating new message to reply for MIG_CMD_POSTCOPY_RESUME. One uint32_t
is used as payload to let the source know whether destination is ready
to continue the migration.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
migration/migration.h | 3 +++
migration/migration.c | 37
The first allow-oob=true command. It's used on destination side when
the postcopy migration is paused and ready for a recovery. After
execution, a new migration channel will be established for postcopy to
continue.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
qapi/migration
This is hook function to be called when a postcopy migration wants to
resume from a failure. For each module, it should provide its own
recovery logic before we switch to the postcopy-active state.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
include/migration/register.h | 2
Introducing new return path message MIG_RP_MSG_RECV_BITMAP to send
received bitmap of ramblock back to source.
This is the reply message of MIG_CMD_RECV_BITMAP, it contains not only
the header (including the ramblock name), and it was appended with the
whole ramblock received bitmap on the destina
From: "Dr. David Alan Gilbert"
Use qemu_set_nonblock rather than a simple fcntl; cleaner
and I have no reason to change other flags.
Reported-by: Peter Maydell
Signed-off-by: Dr. David Alan Gilbert
---
hw/virtio/vhost-user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
Finish the last step to do the final handshake for the recovery.
First source sends one MIG_CMD_RESUME to dst, telling that source is
ready to resume.
Then, dest replies with MIG_RP_MSG_RESUME_ACK to source, telling that
dest is ready to resume (after switch to postcopy-active state).
When sourc
After we updated the dirty bitmaps of ramblocks, we also need to update
the critical fields in RAMState to make sure it is ready for a resume.
Signed-off-by: Peter Xu
---
migration/ram.c| 45 -
migration/trace-events | 1 +
2 files changed, 45
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 20 March 2018 at 03:17, Michael S. Tsirkin wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Register the UFD that comes in as the response to the 'advise' method
> > with the postcopy code.
> >
> > Signed-off-by: Dr. David Alan Gilbert
> >
Sister command to migrate-recover in QMP.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
hmp.h | 1 +
hmp.c | 10 ++
hmp-commands.hx | 13 +
3 files changed, 24 insertions(+)
diff --git a/hmp.h b/hmp.h
index 4e2ec375b0..b6b56c8161 10064
Wrapper for QMP command "migrate-pause".
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
hmp.h | 1 +
hmp.c | 9 +
hmp-commands.hx | 14 ++
3 files changed, 24 insertions(+)
diff --git a/hmp.h b/hmp.h
index b6b56c8161..20f27439d3 100644
Let's introduce a lock for that QEMUFile since we are going to operate
on it in multiple threads.
Signed-off-by: Peter Xu
---
migration/migration.h | 6 ++
migration/channel.c | 3 ++-
migration/migration.c | 22 +++---
3 files changed, 27 insertions(+), 4 deletions(-)
d
On 27/04/2018 18:25, Thomas Huth wrote:
> On 27.04.2018 14:05, David Hildenbrand wrote:
>> If no slots were defined we try to allocate an empty bitmap, which
>> fails.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>>
>> v1 -> v2: more detailed error message
>>
>> hw/mem/pc-dimm.c | 9 -
>>
We shouldn't really have let this expire, the submitter has a patch
attached to the bug.
Yabi: do you have a simple test program which fails without this patch
and works with it? If so can you attach it to the bug ?
** Changed in: qemu
Status: Expired => New
--
You received this bug not
Don't print the tv_nsec part of atime and mtime, to stay below the 10
argument limit of trace events.
Signed-off-by: Greg Kurz
Reviewed-by: Philippe Mathieu-Daudé
---
hw/9pfs/9p.c | 5 +
hw/9pfs/trace-events | 2 ++
2 files changed, 7 insertions(+)
diff --git a/hw/9pfs/9p.c b/hw/9p
The following changes since commit 26bd8d98c4b3284a4c6fe3b67c98b1edd00e9beb:
Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.13-pull-request'
into staging (2018-05-01 15:26:06 +0100)
are available in the Git repository at:
https://github.com/gkurz/qemu.git tags/for-upstream
fo
1 - 100 of 313 matches
Mail list logo
