From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, berrange@redhat.com, armbru@redhat.com,
Claudio Fontana <cfontana@suse.de>, Jim Fehlig <jfehlig@suse.com>,
Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 3/9] tests/qtest/migration: Fix file migration offset check
Date: Fri, 03 May 2024 17:36:59 -0300 [thread overview]
Message-ID: <874jbeocno.fsf@suse.de> (raw)
In-Reply-To: <ZjUVKEJq7LBU57Rf@x1n>
Peter Xu <peterx@redhat.com> writes:
> On Fri, Apr 26, 2024 at 11:20:36AM -0300, Fabiano Rosas wrote:
>> When doing file migration, QEMU accepts an offset that should be
>> skipped when writing the migration stream to the file. The purpose of
>> the offset is to allow the management layer to put its own metadata at
>> the start of the file.
>>
>> We have tests for this in migration-test, but only testing that the
>> migration stream starts at the correct offset and not that it actually
>> leaves the data intact. Unsurprisingly, there's been a bug in that
>> area that the tests didn't catch.
>>
>> Fix the tests to write some data to the offset region and check that
>> it's actually there after the migration.
>>
>> Fixes: 3dc35470c8 ("tests/qtest: migration-test: Add tests for file-based migration")
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>> tests/qtest/migration-test.c | 70 +++++++++++++++++++++++++++++++++---
>> 1 file changed, 65 insertions(+), 5 deletions(-)
>>
>> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
>> index 5d6d8cd634..7b177686b4 100644
>> --- a/tests/qtest/migration-test.c
>> +++ b/tests/qtest/migration-test.c
>> @@ -2081,6 +2081,63 @@ static void test_precopy_file(void)
>> test_file_common(&args, true);
>> }
>>
>> +#ifndef _WIN32
>> +static void file_dirty_offset_region(void)
>> +{
>> +#if defined(__linux__)
>
> Hmm, what's the case to cover when !_WIN32 && __linux__? Can we remove one
> layer of ifdef?
>
> I'm also wondering why it can't work on win32? I thought win32 has all
> these stuff we used here, but I may miss something.
>
__linux__ is because of mmap, !_WIN32 is because of the passing of
fds. We might be able to keep !_WIN32 only, I'll check.
>> + g_autofree char *path = g_strdup_printf("%s/%s", tmpfs, FILE_TEST_FILENAME);
>> + size_t size = FILE_TEST_OFFSET;
>> + uintptr_t *addr, *p;
>> + int fd;
>> +
>> + fd = open(path, O_CREAT | O_RDWR, 0660);
>> + g_assert(fd != -1);
>> +
>> + g_assert(!ftruncate(fd, size));
>> +
>> + addr = mmap(NULL, size, PROT_WRITE, MAP_SHARED, fd, 0);
>> + g_assert(addr != MAP_FAILED);
>> +
>> + /* ensure the skipped offset contains some data */
>> + p = addr;
>> + while (p < addr + FILE_TEST_OFFSET / sizeof(uintptr_t)) {
>> + *p = (unsigned long) FILE_TEST_FILENAME;
>
> This is fine, but not as clear what is assigned.. I think here we assigned
> is the pointer pointing to the binary's RO section (rather than the chars).
Haha you're right, I was assigning the FILE_TEST_OFFSET previously and
just switched to the FILENAME without thinking. I'll fix it up.
> Maybe using some random numbers would be more straightforward, but no
> strong opinions.
>
>> + p++;
>> + }
>> +
>> + munmap(addr, size);
>> + fsync(fd);
>> + close(fd);
>> +#endif
>> +}
>> +
>> +static void *file_offset_start_hook(QTestState *from, QTestState *to)
>> +{
>> + g_autofree char *file = g_strdup_printf("%s/%s", tmpfs, FILE_TEST_FILENAME);
>> + int src_flags = O_WRONLY;
>> + int dst_flags = O_RDONLY;
>> + int fds[2];
>> +
>> + file_dirty_offset_region();
>> +
>> + fds[0] = open(file, src_flags, 0660);
>> + assert(fds[0] != -1);
>> +
>> + fds[1] = open(file, dst_flags, 0660);
>> + assert(fds[1] != -1);
>> +
>> + qtest_qmp_fds_assert_success(from, &fds[0], 1, "{'execute': 'add-fd', "
>> + "'arguments': {'fdset-id': 1}}");
>> +
>> + qtest_qmp_fds_assert_success(to, &fds[1], 1, "{'execute': 'add-fd', "
>> + "'arguments': {'fdset-id': 1}}");
>> +
>> + close(fds[0]);
>> + close(fds[1]);
>> +
>> + return NULL;
>> +}
>> +
>> static void file_offset_finish_hook(QTestState *from, QTestState *to,
>> void *opaque)
>> {
>> @@ -2096,12 +2153,12 @@ static void file_offset_finish_hook(QTestState *from, QTestState *to,
>> g_assert(addr != MAP_FAILED);
>>
>> /*
>> - * Ensure the skipped offset contains zeros and the migration
>> - * stream starts at the right place.
>> + * Ensure the skipped offset region's data has not been touched
>> + * and the migration stream starts at the right place.
>> */
>> p = addr;
>> while (p < addr + FILE_TEST_OFFSET / sizeof(uintptr_t)) {
>> - g_assert(*p == 0);
>> + g_assert_cmpstr((char *) *p, ==, FILE_TEST_FILENAME);
>> p++;
>> }
>> g_assert_cmpint(cpu_to_be64(*p) >> 32, ==, QEMU_VM_FILE_MAGIC);
>> @@ -2113,17 +2170,18 @@ static void file_offset_finish_hook(QTestState *from, QTestState *to,
>>
>> static void test_precopy_file_offset(void)
>> {
>> - g_autofree char *uri = g_strdup_printf("file:%s/%s,offset=%d", tmpfs,
>> - FILE_TEST_FILENAME,
>> + g_autofree char *uri = g_strdup_printf("file:/dev/fdset/1,offset=%d",
>> FILE_TEST_OFFSET);
>
> Do we want to keep both tests to cover both normal file and fdsets?
>
I think the fdset + offset is the most complex in terms of requirements,
so I don't think we need to test the other one.
I'm actually already a bit concerned about the amount of tests we
have. I was even thinking of starting playing with some code coverage
tools and prune some of the tests if possible.
>> MigrateCommon args = {
>> .connect_uri = uri,
>> .listen_uri = "defer",
>> + .start_hook = file_offset_start_hook,
>> .finish_hook = file_offset_finish_hook,
>> };
>>
>> test_file_common(&args, false);
>> }
>> +#endif
>>
>> static void test_precopy_file_offset_bad(void)
>> {
>> @@ -3636,8 +3694,10 @@ int main(int argc, char **argv)
>>
>> migration_test_add("/migration/precopy/file",
>> test_precopy_file);
>> +#ifndef _WIN32
>> migration_test_add("/migration/precopy/file/offset",
>> test_precopy_file_offset);
>> +#endif
>> migration_test_add("/migration/precopy/file/offset/bad",
>> test_precopy_file_offset_bad);
>>
>> --
>> 2.35.3
>>
next prev parent reply other threads:[~2024-05-03 20:37 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 14:20 [PATCH 0/9] migration/mapped-ram: Add direct-io support Fabiano Rosas
2024-04-26 14:20 ` [PATCH 1/9] monitor: Honor QMP request for fd removal immediately Fabiano Rosas
2024-05-03 16:02 ` Peter Xu
2024-05-16 21:46 ` Fabiano Rosas
2024-05-08 7:17 ` Daniel P. Berrangé
2024-05-16 22:00 ` Fabiano Rosas
2024-05-17 7:33 ` Daniel P. Berrangé
2024-04-26 14:20 ` [PATCH 2/9] migration: Fix file migration with fdset Fabiano Rosas
2024-05-03 16:23 ` Peter Xu
2024-05-03 19:56 ` Fabiano Rosas
2024-05-03 21:04 ` Peter Xu
2024-05-03 21:31 ` Fabiano Rosas
2024-05-03 21:56 ` Peter Xu
2024-05-08 8:02 ` Daniel P. Berrangé
2024-05-08 12:49 ` Peter Xu
2024-05-08 8:00 ` Daniel P. Berrangé
2024-05-08 20:45 ` Fabiano Rosas
2024-04-26 14:20 ` [PATCH 3/9] tests/qtest/migration: Fix file migration offset check Fabiano Rosas
2024-05-03 16:47 ` Peter Xu
2024-05-03 20:36 ` Fabiano Rosas [this message]
2024-05-03 21:08 ` Peter Xu
2024-05-08 8:10 ` Daniel P. Berrangé
2024-04-26 14:20 ` [PATCH 4/9] migration: Add direct-io parameter Fabiano Rosas
2024-04-26 14:33 ` Markus Armbruster
2024-05-03 18:05 ` Peter Xu
2024-05-03 20:49 ` Fabiano Rosas
2024-05-03 21:16 ` Peter Xu
2024-05-14 14:10 ` Markus Armbruster
2024-05-14 17:57 ` Fabiano Rosas
2024-05-15 7:17 ` Markus Armbruster
2024-05-15 12:51 ` Fabiano Rosas
2024-05-08 8:25 ` Daniel P. Berrangé
2024-04-26 14:20 ` [PATCH 5/9] migration/multifd: Add direct-io support Fabiano Rosas
2024-05-03 18:29 ` Peter Xu
2024-05-03 20:54 ` Fabiano Rosas
2024-05-03 21:18 ` Peter Xu
2024-05-08 8:27 ` Daniel P. Berrangé
2024-04-26 14:20 ` [PATCH 6/9] tests/qtest/migration: Add tests for file migration with direct-io Fabiano Rosas
2024-05-03 18:38 ` Peter Xu
2024-05-03 21:05 ` Fabiano Rosas
2024-05-03 21:25 ` Peter Xu
2024-05-08 8:34 ` Daniel P. Berrangé
2024-04-26 14:20 ` [PATCH 7/9] monitor: fdset: Match against O_DIRECT Fabiano Rosas
2024-05-03 18:53 ` Peter Xu
2024-05-03 21:19 ` Fabiano Rosas
2024-05-03 22:16 ` Peter Xu
2024-04-26 14:20 ` [PATCH 8/9] migration: Add support for fdset with multifd + file Fabiano Rosas
2024-05-08 8:53 ` Daniel P. Berrangé
2024-05-08 18:23 ` Peter Xu
2024-05-08 20:39 ` Fabiano Rosas
2024-05-09 8:08 ` Daniel P. Berrangé
2024-05-17 22:43 ` Fabiano Rosas
2024-05-18 8:36 ` Daniel P. Berrangé
2024-04-26 14:20 ` [PATCH 9/9] tests/qtest/migration: Add a test for mapped-ram with passing of fds Fabiano Rosas
2024-05-08 8:56 ` Daniel P. Berrangé
2024-05-02 20:01 ` [PATCH 0/9] migration/mapped-ram: Add direct-io support Peter Xu
2024-05-02 20:34 ` Fabiano Rosas
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=874jbeocno.fsf@suse.de \
--to=farosas@suse.de \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=cfontana@suse.de \
--cc=jfehlig@suse.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--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.