From: Juan Quintela <quintela@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, amit.shah@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/3] migration: Test for disabled features on reception
Date: Tue, 15 Nov 2016 11:07:13 +0100 [thread overview]
Message-ID: <87shqtcazy.fsf@emacs.mitica> (raw)
In-Reply-To: <20161115095403.GD2038@work-vm> (David Alan Gilbert's message of "Tue, 15 Nov 2016 09:54:03 +0000")
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>> Right now, if we receive a compressed page or a xbzrle page while this
>> features are disabled, Bad Things (TM) can happen. Just add a test for
>> them.
>
> This confuses me; I didn't think until recently we could
> guarantee anything about having the capabilities set on the destination
> side. Until -incoming defer the destination didn't have a way of setting
> capabilities in a known state before starting the reception.
Ouch.
So, here we are after further investigation.
- xbzrle: we don't need anything special on the reception side, we just
decode inplace. So we are good. If we don't use xbzrle, we
don't waste any resources either.
- compression: We create the decompression threads always, with all its
associated configuration.
Why do I wanted to do this? For multifd, I don't really want to create
multiple fd's except if configured, because I wait for the fd's to be
"accepted" before continue, so I need a way to know if it is configured
or no. So I need something like this.
I started doing this for compression because when I was debugging I had
too many threads waiting on qemu_cond_wait(), and I only wanted to look
at the multifd ones.
I had not througth that we didn't need to set capabilities on
destination.
Suggestions?
Later, Juan.
>
> Dave
>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>> migration/ram.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/migration/ram.c b/migration/ram.c
>> index fb9252d..4bb707c 100644
>> --- a/migration/ram.c
>> +++ b/migration/ram.c
>> @@ -2464,7 +2464,7 @@ static int ram_load_postcopy(QEMUFile *f)
>>
>> static int ram_load(QEMUFile *f, void *opaque, int version_id)
>> {
>> - int flags = 0, ret = 0;
>> + int flags = 0, ret = 0, invalid_flags;
>> static uint64_t seq_iter;
>> int len = 0;
>> /*
>> @@ -2479,6 +2479,15 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
>> ret = -EINVAL;
>> }
>>
>> + invalid_flags = 0;
>> +
>> + if (!migrate_use_xbzrle()) {
>> + invalid_flags |= RAM_SAVE_FLAG_XBZRLE;
>> + }
>> +
>> + if (!migrate_use_compression()) {
>> + invalid_flags |= RAM_SAVE_FLAG_COMPRESS_PAGE;
>> + }
>> /* This RCU critical section can be very long running.
>> * When RCU reclaims in the code start to become numerous,
>> * it will be necessary to reduce the granularity of this
>> @@ -2499,6 +2508,18 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
>> flags = addr & ~TARGET_PAGE_MASK;
>> addr &= TARGET_PAGE_MASK;
>>
>> + if (flags & invalid_flags) {
>> + if (flags & invalid_flags & RAM_SAVE_FLAG_XBZRLE) {
>> + error_report("Received an unexpected XBRLE page");
>> + }
>> + if (flags & invalid_flags & RAM_SAVE_FLAG_COMPRESS_PAGE) {
>> + error_report("Received an unexpected compressed page");
>> + }
>> +
>> + ret = -EINVAL;
>> + break;
>> + }
>> +
>> if (flags & (RAM_SAVE_FLAG_COMPRESS | RAM_SAVE_FLAG_PAGE |
>> RAM_SAVE_FLAG_COMPRESS_PAGE | RAM_SAVE_FLAG_XBZRLE)) {
>> RAMBlock *block = ram_block_from_stream(f, flags);
>> --
>> 2.7.4
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2016-11-15 10:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 20:55 [Qemu-devel] [PATCH 0/3] Migration fixes Juan Quintela
2016-11-14 20:55 ` [Qemu-devel] [PATCH 1/3] migration: create Migration Incoming State at init time Juan Quintela
2016-11-15 9:50 ` Dr. David Alan Gilbert
2016-11-14 20:55 ` [Qemu-devel] [PATCH 2/3] migration: Test for disabled features on reception Juan Quintela
2016-11-15 9:54 ` Dr. David Alan Gilbert
2016-11-15 10:07 ` Juan Quintela [this message]
2016-11-15 10:42 ` Dr. David Alan Gilbert
2016-11-14 20:55 ` [Qemu-devel] [PATCH 3/3] migration: Don't create decompression threads if not enabled Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shqtcazy.fsf@emacs.mitica \
--to=quintela@redhat.com \
--cc=amit.shah@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.