[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/5] migration: ram_release_pages() always receive 1 page as
From: |
Juan Quintela |
Subject: |
Re: [PATCH 3/5] migration: ram_release_pages() always receive 1 page as argument |
Date: |
Tue, 21 Dec 2021 10:35:50 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> On 12/16/21 10:13, Juan Quintela wrote:
>> Remove the pages argument. And s/pages/page/
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>> migration/ram.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>> -static void ram_release_pages(const char *rbname, uint64_t offset, int
>> pages)
>> +static void ram_release_page(const char *rbname, uint64_t offset)
>> {
>> if (!migrate_release_ram() || !migration_in_postcopy()) {
>> return;
>> }
>>
>> - ram_discard_range(rbname, offset, ((ram_addr_t)pages) <<
>> TARGET_PAGE_BITS);
>> + ram_discard_range(rbname, offset, ((ram_addr_t)1) << TARGET_PAGE_BITS);
>
> 1ULL?
I am changing it, but the argument to ram_discard_range is a size_t, and
that is different in 32 bits arch. Once told that, it is not worse that
what we have here, as ram_addr_t type depends on the phase of the moon.
/* address in the RAM (different from a physical address) */
#if defined(CONFIG_XEN_BACKEND)
typedef uint64_t ram_addr_t;
# define RAM_ADDR_MAX UINT64_MAX
# define RAM_ADDR_FMT "%" PRIx64
#else
typedef uintptr_t ram_addr_t;
# define RAM_ADDR_MAX UINTPTR_MAX
# define RAM_ADDR_FMT "%" PRIxPTR
#endif
Later, Juan.
PD. No, I don't know either why it is not casted to size_t.
PD2. And yes, I still think that pure int operations should be ok.
The value TARGET_PAGE_BITS more typical is 10, and here pages is
only used with value 1. C promotion rules should make everything
ok (famous last words).