All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	pbonzini@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 1/2] memory: export migration page size
Date: Mon, 19 Aug 2013 11:59:25 +0200	[thread overview]
Message-ID: <5211EC7D.8040209@redhat.com> (raw)
In-Reply-To: <1376347400-21035-2-git-send-email-mst@redhat.com>

On 08/13/13 00:43, Michael S. Tsirkin wrote:
> Migration code assumes that each RAM block is a multiple of target page
> size.

Isn't that a valid assumption, considering the TARGET_PAGE_ALIGN() macro
call in qemu_ram_alloc_from_ptr() [exec.c]?

> We can fix this in a variety of ways, the simplest way is
> exporting the required page size so callers can make regions
> large enough.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>  arch_init.c           | 6 ++++++
>  include/exec/memory.h | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch_init.c b/arch_init.c
> index 68a7ab7..c62778f 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -150,6 +150,12 @@ int qemu_read_default_config_files(bool userconfig)
>      return 0;
>  }
>  
> +/* Smallest page size for migrated RAM. */
> +uint64_t qemu_migration_page_size(void)
> +{
> +    return TARGET_PAGE_SIZE;
> +}
> +
>  static inline bool is_zero_page(uint8_t *p)
>  {
>      return buffer_find_nonzero_offset(p, TARGET_PAGE_SIZE) ==
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index ebe0d24..6ffffa2 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
> @@ -1055,6 +1055,7 @@ void *address_space_map(AddressSpace *as, hwaddr addr,
>  void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len,
>                           int is_write, hwaddr access_len);
>  
> +extern uint64_t qemu_migration_page_size(void);
>  
>  #endif

External linkage functions that are defined in "arch_init.c", and relate
to migration -- for example, skipped_mig_bytes_transferred() -- are
declared in "include/migration/migration.h". They seem to use
TARGET_PAGE_SIZE too.

What justifies declaring this new function in "include/exec/memory.h"?

Thanks,
Laszlo

  reply	other threads:[~2013-08-19  9:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12 22:43 [Qemu-devel] [PATCH v3 0/2] future proof rom loading for cross versiom migration Michael S. Tsirkin
2013-08-12 22:43 ` [Qemu-devel] [PATCH v3 1/2] memory: export migration page size Michael S. Tsirkin
2013-08-19  9:59   ` Laszlo Ersek [this message]
2013-08-19 10:21     ` Peter Maydell
2013-08-19 11:09       ` Laszlo Ersek
2013-08-19 11:18         ` Michael S. Tsirkin
2013-08-19 11:33           ` Laszlo Ersek
2013-08-19 11:05     ` Michael S. Tsirkin
2013-08-12 22:43 ` [Qemu-devel] [PATCH v3 2/2] loader: put FW CFG ROM files into RAM Michael S. Tsirkin
2013-08-19 11:06   ` Laszlo Ersek
2013-08-19 11:10     ` Michael S. Tsirkin
2013-08-19 11:15     ` Laszlo Ersek
2013-08-19 11:21       ` Michael S. Tsirkin
2013-08-18 13:41 ` [Qemu-devel] [PATCH v3 0/2] future proof rom loading for cross versiom migration Michael S. Tsirkin
2013-08-19 11:37 ` Laszlo Ersek

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=5211EC7D.8040209@redhat.com \
    --to=lersek@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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.