From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: "Steven Sistare" <steven.sistare@oracle.com>,
qemu-devel@nongnu.org, "Juan Quintela" <quintela@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Leonardo Bras" <leobras@redhat.com>
Subject: Re: [PATCH V6 05/14] migration: propagate suspended runstate
Date: Tue, 05 Dec 2023 13:52:16 -0300 [thread overview]
Message-ID: <877clsmw1r.fsf@suse.de> (raw)
In-Reply-To: <ZW9NcwNropqV_7Kz@x1n>
Peter Xu <peterx@redhat.com> writes:
> On Tue, Dec 05, 2023 at 09:44:12AM -0300, Fabiano Rosas wrote:
>> Peter Xu <peterx@redhat.com> writes:
>>
>> > On Mon, Dec 04, 2023 at 06:09:16PM -0300, Fabiano Rosas wrote:
>> >> Right, I got your point. I just think we could avoid designing this new
>> >> string format by creating new fields with the extra space:
>> >>
>> >> typedef struct QEMU_PACKED {
>> >> uint32_t size;
>> >> uint8_t runstate[50];
>> >> uint8_t unused[50];
>> >> RunState state;
>> >> bool received;
>> >> } GlobalState;
>> >>
>> >> In my mind this works seamlessly, or am I mistaken?
>> >
>> > I think what you proposed should indeed work.
>> >
>> > Currently it's:
>> >
>> > .fields = (VMStateField[]) {
>> > VMSTATE_UINT32(size, GlobalState),
>> > VMSTATE_BUFFER(runstate, GlobalState),
>> > VMSTATE_END_OF_LIST()
>> > },
>> >
>> > I had a quick look at vmstate_info_buffer, it mostly only get()/put() those
>> > buffers with its sizeof(), so looks all fine. For sure in all cases we'd
>> > better test it to verify.
>> >
>> > One side note is since we so far use qapi_enum_parse() for the runstate, I
>> > think the "size" is not ever used..
>> >
>> > If we do want a split, IMHO we can consider making runstate[] even smaller
>> > to just free up the rest spaces all in one shot:
>> >
>> > typedef struct QEMU_PACKED {
>
> [1]
>
>> > uint32_t size;
>> > /*
>> > * Assuming 16 is good enough to fit all possible runstate strings..
>> > * This field must be a string ending with '\0'.
>> > */
>> > uint8_t runstate[16];
>> > /* 0x00 when QEMU doesn't support it, or "0"/"1" to reflect its state */
>> > uint8_t vm_was_suspended[1];
>> > /*
>> > * Still free of use space. Note that we only have 99 bytes for use
>> > * because the last byte (the 100th byte) must be zero due to legacy
>> > * reasons, if not it may be set to zero after loaded on dest QEMU.
>> > */
>>
>> I'd add a 'uint8_t reserved;' to go along with this comment instead of
>> leaving a hole.
>
> Note that "struct GlobalState" is not a binary format but only some
> internal storage, what really matters is vmstate_globalstate. Here the
> "uint8_reserved" will be a pure waste of 1 byte in QEMU binary, imho.
>
I prefer wasting the byte and make the code more obvious to people who
might not immediately understand what's going on. We could even
assert(!global_state.reserved) to sanity check the assumption. Anyway,
that's minor, I'm fine with it either way.
> I think I just copied what you had previously and extended it, logically I
> don't think we ever need QEMU_PACKED right above [1]. We can also drop
> "size" directly here, but this can be done later.
Ah right, I was initially thinking of letting the new qemu overrun
runstate[16] so we wouldn't have to change the code. But that's indeed
not necessary, your additions to the vmstate make it ok. Thanks.
next prev parent reply other threads:[~2023-12-05 16:53 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 21:37 [PATCH V6 00/14] fix migration of suspended runstate Steve Sistare
2023-11-30 21:37 ` [PATCH V6 01/14] cpus: pass runstate to vm_prepare_start Steve Sistare
2023-11-30 21:37 ` [PATCH V6 02/14] cpus: vm_was_suspended Steve Sistare
2023-11-30 22:03 ` Peter Xu
2023-11-30 21:37 ` [PATCH V6 03/14] cpus: stop vm in suspended runstate Steve Sistare
2023-11-30 22:10 ` Peter Xu
2023-12-01 17:11 ` Steven Sistare
2023-12-04 16:35 ` Peter Xu
2023-12-04 16:41 ` Steven Sistare
2023-12-22 12:20 ` Markus Armbruster
2023-12-22 15:53 ` Steven Sistare
2023-12-23 5:41 ` Markus Armbruster
2024-01-03 13:09 ` Peter Xu
2024-01-03 13:32 ` Steven Sistare
2024-01-03 14:47 ` Steven Sistare
2024-01-08 7:43 ` Markus Armbruster
2023-11-30 21:37 ` [PATCH V6 04/14] cpus: vm_resume Steve Sistare
2023-12-05 21:36 ` Peter Xu
2023-11-30 21:37 ` [PATCH V6 05/14] migration: propagate suspended runstate Steve Sistare
2023-11-30 23:06 ` Peter Xu
2023-12-01 16:23 ` Steven Sistare
2023-12-04 17:24 ` Peter Xu
2023-12-04 19:31 ` Fabiano Rosas
2023-12-04 20:02 ` Peter Xu
2023-12-04 21:09 ` Fabiano Rosas
2023-12-04 22:04 ` Peter Xu
2023-12-05 12:44 ` Fabiano Rosas
2023-12-05 14:14 ` Steven Sistare
2023-12-05 16:18 ` Peter Xu
2023-12-05 16:52 ` Fabiano Rosas [this message]
2023-12-05 17:04 ` Steven Sistare
2023-12-04 22:23 ` Steven Sistare
2023-12-05 16:50 ` Peter Xu
2023-12-05 17:48 ` Steven Sistare
2023-11-30 21:37 ` [PATCH V6 06/14] migration: preserve " Steve Sistare
2023-12-05 21:34 ` Peter Xu
2023-11-30 21:37 ` [PATCH V6 07/14] migration: preserve suspended for snapshot Steve Sistare
2023-12-05 21:35 ` Peter Xu
2023-11-30 21:37 ` [PATCH V6 08/14] migration: preserve suspended for bg_migration Steve Sistare
2023-12-05 21:35 ` Peter Xu
2023-11-30 21:37 ` [PATCH V6 09/14] tests/qtest: migration events Steve Sistare
2023-11-30 21:37 ` [PATCH V6 10/14] tests/qtest: option to suspend during migration Steve Sistare
2023-12-04 21:14 ` Fabiano Rosas
2023-11-30 21:37 ` [PATCH V6 11/14] tests/qtest: precopy migration with suspend Steve Sistare
2023-12-04 20:49 ` Peter Xu
2023-12-05 16:14 ` Steven Sistare
2023-12-05 21:07 ` Peter Xu
2023-11-30 21:37 ` [PATCH V6 12/14] tests/qtest: postcopy " Steve Sistare
2023-11-30 21:37 ` [PATCH V6 13/14] tests/qtest: bootfile per vm Steve Sistare
2023-12-04 21:13 ` Fabiano Rosas
2023-12-04 22:37 ` Peter Xu
2023-12-05 18:43 ` Steven Sistare
2023-11-30 21:37 ` [PATCH V6 14/14] tests/qtest: background migration with suspend Steve Sistare
2023-12-04 21:14 ` Fabiano Rosas
2023-12-05 18:52 ` [PATCH V6 00/14] fix migration of suspended runstate Steven Sistare
2023-12-05 19:19 ` Fabiano Rosas
2023-12-05 21:37 ` Peter Xu
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=877clsmw1r.fsf@suse.de \
--to=farosas@suse.de \
--cc=berrange@redhat.com \
--cc=leobras@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=steven.sistare@oracle.com \
--cc=thuth@redhat.com \
/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.