From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: quintela@redhat.com, qemu-devel@nongnu.org,
Peter Xu <peterx@redhat.com>,
eric.auger.pro@gmail.com
Subject: Re: [PATCH v3] migration: Support gtree migration
Date: Thu, 10 Oct 2019 19:53:51 +0100 [thread overview]
Message-ID: <20191010185351.GG3292@work-vm> (raw)
In-Reply-To: <7930bbdf-1ada-d25d-dd40-1580d421e42f@redhat.com>
* Auger Eric (eric.auger@redhat.com) wrote:
> Hi peter,
>
> On 10/10/19 2:35 PM, Peter Xu wrote:
> > On Thu, Oct 10, 2019 at 02:11:46PM +0200, Auger Eric wrote:
> >>>>> Also, should we avoid using UINT in all cases? But of course if we
> >>>>> start to use VMSTATE_UINT32_V then we don't have this issue.
> >>>> Depending on the clarification of above point, maybe I can rename
> >>>> VMSTATE_GTREE_DIRECT_KEY_V into VMSTATE_GTREE_DIRECT_UINT_KEY_V
> >>>>
> >>>> direct keys seem to be more common for hash tables actually.
> >>>> https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-new-full
> >>>>
> >>>> There are stand conversion macros to/from int, uint, size
> >>>> https://developer.gnome.org/glib/stable/glib-Type-Conversion-Macros.html
> >>>
> >>> Yeh it's fine to use direct keys. Though my question was more about
> >>> "unsigned int" - here when we put, we cast a pointer into unsigned
> >>> int, which can be 2/4 bytes, IIUC. I'm thinking whether at least we
> >>> should use direct cast (e.g., (uint32_t)ptr) to replace
> >>> GPOINTER_TO_UINT() to make sure it's 4 bytes. Futher, maybe we should
> >>> start with uint64_t here in the migration stream, otherwise we should
> >>> probably drop the high 32 bits if we migrate a gtree whose key is 64
> >>> bits long (and since we're working with migration we won't be able to
> >>> change that in the future for compatibility reasons...).
> >>>
> >>> Summary:
> >>>
> >>> Maybe we can replace:
> >>>
> >>> qemu_put_be32(f, GPOINTER_TO_UINT(key)); /* direct key */
> >>>
> >>> To:
> >>>
> >>> qemu_put_be64(f, (uint64_t)key); /* direct key */
> >>>
> >>> And apply similar thing to get() side?
> >>
> >> This was my first idea as well but I got stuck with a mingw compilation
> >> issues if I remember correctly, trying to cast pointers to a wrong sized
> >> uint. This got removed by using the GPOINTER_TO_UINT conversion functions.
> >
> > #define GPOINTER_TO_UINT(p) ((guint) (gulong) (p))
> >
> > Could "(uint64_t)(uintptr_t)pointer" do the work?
> the problem rather is on the get side, when you cast the uint64_t value
> into the pointer. it does not compile with
>
> make docker-test-mingw@fedora
>
>
> /tmp/qemu-test/src/migration/vmstate-types.c:800:19: error: cast to
> pointer from integer of different size [-Werror=int-to-pointer-cast]
> key = (void *)(uint64_t)qemu_get_be64(f);
>
> I would be tempted to rename the macro to emphasize the key is an
> uint32. It should cover most of the use cases, no?
Try:
(void *)(uintptr_t)qemu_get_be64(f)
>
> Thanks
>
> Eric
>
>
> >
> > Thanks,
> >
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-10-10 18:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 11:20 [PATCH v3] migration: Support gtree migration Eric Auger
2019-10-04 22:34 ` Juan Quintela
2019-10-10 7:32 ` Auger Eric
2019-10-09 6:28 ` Peter Xu
2019-10-10 7:57 ` Auger Eric
2019-10-10 11:35 ` Peter Xu
2019-10-10 12:11 ` Auger Eric
2019-10-10 12:35 ` Peter Xu
2019-10-10 18:52 ` Auger Eric
2019-10-10 18:53 ` Dr. David Alan Gilbert [this message]
2019-10-10 19:42 ` Auger Eric
2019-10-09 9:57 ` Dr. David Alan Gilbert
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=20191010185351.GG3292@work-vm \
--to=dgilbert@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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.