From: Juan Quintela <quintela@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>,
Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH 1/2] migration: Boost SaveStateEntry.instance_id to 64 bits
Date: Tue, 15 Oct 2019 10:34:57 +0200 [thread overview]
Message-ID: <87tv8aqudq.fsf@trasno.org> (raw)
In-Reply-To: <20191015075444.10955-2-peterx@redhat.com> (Peter Xu's message of "Tue, 15 Oct 2019 15:54:43 +0800")
Peter Xu <peterx@redhat.com> wrote:
> It was "int" and used as 32bits fields (see save_section_header()).
> It's unsafe already because sizeof(int) could be 2 on i386,
i386 is 32bits, so int is 32bits O:-)
I really hope that we would never, ever, need a 64bits instance id.
It would mean that we have more than 2.000.000.000 objects of the same
type, no?
I am pretty sure than in 16bits platforms we have other problems than
insntance_id (namely that we don't have enough memory).
>I think.
> So at least uint32_t would suite more. While it also uses "-1" as a
> placeholder of "we want to generate the instance ID automatically".
> Hence a more proper value should be int64_t.
>
> This will start to be useful after next patch in which we can start to
> convert a real uint32_t value as instance ID.
Later, Juan.
next prev parent reply other threads:[~2019-10-15 8:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 7:54 [PATCH 0/2] apic: Fix migration breakage of >255 vcpus Peter Xu
2019-10-15 7:54 ` [PATCH 1/2] migration: Boost SaveStateEntry.instance_id to 64 bits Peter Xu
2019-10-15 8:34 ` Juan Quintela [this message]
2019-10-15 10:28 ` Peter Xu
2019-10-15 8:45 ` Juan Quintela
2019-10-15 8:57 ` Dr. David Alan Gilbert
2019-10-15 12:57 ` Juan Quintela
2019-10-15 10:23 ` Peter Xu
2019-10-15 7:54 ` [PATCH 2/2] apic: Use 32bit APIC ID for migration instance ID Peter Xu
2019-10-15 8:30 ` Juan Quintela
2019-10-15 9:22 ` Dr. David Alan Gilbert
2019-10-15 10:16 ` Peter Xu
2019-10-15 11:02 ` Dr. David Alan Gilbert
2019-10-15 19:49 ` Eduardo Habkost
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=87tv8aqudq.fsf@trasno.org \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@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.