All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Alexey Perevalov <a.perevalov@samsung.com>
Cc: qemu-devel@nongnu.org, peterx@redhat.com, i.maximets@samsung.com,
	dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 3/3] migration: add bitmap for received page
Date: Wed, 21 Jun 2017 21:22:07 +0200	[thread overview]
Message-ID: <87h8z9jgdc.fsf@secure.laptop> (raw)
In-Reply-To: <1497640120-10729-4-git-send-email-a.perevalov@samsung.com> (Alexey Perevalov's message of "Fri, 16 Jun 2017 22:08:40 +0300")

Alexey Perevalov <a.perevalov@samsung.com> wrote:
> This patch adds ability to track down already received
> pages, it's necessary for calculation vCPU block time in
> postcopy migration feature, maybe for restore after
> postcopy migration failure.
> Also it's necessary to solve shared memory issue in
> postcopy livemigration. Information about received pages
> will be transferred to the software virtual bridge
> (e.g. OVS-VSWITCHD), to avoid fallocate (unmap) for
> already received pages. fallocate syscall is required for
> remmaped shared memory, due to remmaping itself blocks
> ioctl(UFFDIO_COPY, ioctl in this case will end with EEXIT
> error (struct page is exists after remmap).
>
> Bitmap is placed into RAMBlock as another postcopy/precopy
> related bitmaps.
>
> Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com>

Hi

A few commets.

Happy with all the changes that you did.

> @@ -60,6 +62,7 @@ static inline void *ramblock_ptr(RAMBlock *block, ram_addr_t offset)
>     return (char *)block->host + offset;
> }
> 
> +unsigned long int ramblock_recv_bitmap_offset(void *host_addr, RAMBlock *rb);
>  long qemu_getrampagesize(void);
>  unsigned long last_ram_page(void);
> RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,

I think we shouldn't export it at all.  But if we do, we should export
it with the other functions.


> +unsigned long int ramblock_recv_bitmap_offset(void *host_addr, RAMBlock *rb)

I think this function can be made static, as nothing else should use it, no?

> +{
> +    uint64_t host_addr_offset = (uint64_t)(uintptr_t)(host_addr
> +                                                      - (void *)rb->host);

Intdentation is weird:

uint64_t host_addr_offset =
    (uint64_t)(uintptr_t)(host_addr - (void *)rb->host);


> +    return host_addr_offset >> TARGET_PAGE_BITS;
> +}
> +
> +int ramblock_recv_bitmap_test(void *host_addr, RAMBlock *rb)
> +{
> +    return test_bit(ramblock_recv_bitmap_offset(host_addr, rb),
> +                    rb->receivedmap);
> +}
> +
> +void ramblock_recv_bitmap_set(void *host_addr, RAMBlock *rb)
> +{
> +    set_bit_atomic(ramblock_recv_bitmap_offset(host_addr, rb),
> rb->receivedmap);

Line is too long?

> +static void ramblock_recv_bitmap_clear_range(uint64_t start, size_t length,
> +                                             RAMBlock *rb)
> +{
> +    int i, range_count;
> +    range_count = length >> TARGET_PAGE_BITS;
> +    for (i = 0; i < range_count; i++) {
> +        ramblock_recv_bitmap_clear((void *)((uint64_t)(intptr_t)rb->host +
> +                                            start), rb);
> +        start += TARGET_PAGE_SIZE;

bitmap_clear(dst, pos, nbits)		Clear specified bit area

Looks like the right operation here, no?

> +
> +void ramblock_recv_map_init(void);
> +int ramblock_recv_bitmap_test(void *host_addr, RAMBlock *rb);
> +void ramblock_recv_bitmap_set(void *host_addr, RAMBlock *rb);
> +void ramblock_recv_bitmap_clear(void *host_addr, RAMBlock *rb);
> +
>  #endif

Later, Juan.

  reply	other threads:[~2017-06-21 19:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170616190851eucas1p123df3a9fe01d3c2a81bfe45906d07f0d@eucas1p1.samsung.com>
2017-06-16 19:08 ` [Qemu-devel] [PATCH v3 0/3] Add bitmap for received pages in postcopy migration Alexey Perevalov
2017-06-16 19:08   ` [Qemu-devel] [PATCH v3 1/3] migration: postcopy_place_page factoring out Alexey Perevalov
2017-06-16 19:08   ` [Qemu-devel] [PATCH v3 2/3] migration: introduce qemu_ufd_copy_ioctl helper Alexey Perevalov
2017-06-21 12:11     ` Juan Quintela
2017-06-16 19:08   ` [Qemu-devel] [PATCH v3 3/3] migration: add bitmap for received page Alexey Perevalov
2017-06-21 19:22     ` Juan Quintela [this message]
2017-06-23 15:35       ` Perevalov Alexey
2017-06-23 10:29     ` Dr. David Alan Gilbert
2017-06-23 15:19       ` Perevalov Alexey
2017-06-23 19:41         ` Dr. David Alan Gilbert
2017-06-24  5:11           ` Perevalov Alexey

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=87h8z9jgdc.fsf@secure.laptop \
    --to=quintela@redhat.com \
    --cc=a.perevalov@samsung.com \
    --cc=dgilbert@redhat.com \
    --cc=i.maximets@samsung.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.