From: Igor Mammedov <imammedo@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: pbonzini@redhat.com, rth@twiddle.net, qemu-devel@nongnu.org,
ehabkost@redhat.com, mst@redhat.com
Subject: Re: [PATCH for-5.0] xen: fixup RAM memory region initialization
Date: Wed, 8 Apr 2020 10:45:36 +0200 [thread overview]
Message-ID: <20200408104536.4a353c10@redhat.com> (raw)
In-Reply-To: <20200407113634.GW4088@perard.uk.xensource.com>
On Tue, 7 Apr 2020 12:36:34 +0100
Anthony PERARD <anthony.perard@citrix.com> wrote:
> On Thu, Apr 02, 2020 at 04:30:33PM +0200, Igor Mammedov wrote:
> > 1. why xen uses memory_region_init_ram() which does not allocate anything
>
> This seems to be due to history.
>
> > can it use plain memory_region_init() instead?
>
> I can give it a try. And it doesn't work, I had to call qemu_ram_alloc() as
> well, to set ram_memory.c.
>
> On the other and, I think memory_region_init_ram_nomigrate() would be
> enough. QEMU didn't complain when I migrated the guest.
Why does it need ramblock fir main ram if it does not allocate nor migrate
it using QEMU infrastructure?
>
> > 2. how main ram is allocated?
>
> It's done by the toolstack, libxl. It creates a new domain in the
> hypervisor, memory allocation is part of this, then QEMU is started, for
> emulation of some devices.
>
> There is one thing that QEMU does in regards to memory, it's the call
> xc_domain_populate_physmap_exact() in xen_ram_alloc(). This is for when
> an emulated PCI device needs some memory, like for the VGA region.
>
> > 3. code has
> > /*
> > * Xen does not allocate the memory continuously, it keeps a
> > * hole of the size computed above or passed in.
> > */
> > block_len = (1ULL << 32) + x86ms->above_4g_mem_size;
> > which fixes up size ram memory region
> > can we allocate 1 memory region of ram_size and then
> > alias lower and upper memory instead of that?
>
> I don't know, I don't think I know enough about how memory_region are
> used to be able to answer that.
>
> > 4. how RAM migration works in case of xen?
>
> From QEMU, we only migrate devices states, we call the
> "xen-save-devices-state" QMP command. Memory migration is done by the
> toolstack. In QEMU, there is a bodge in xen_ram_alloc() to avoid having
> QEMU doing some "allocation" during migration.
>
> I hope that help.
> Cheers,
>
prev parent reply other threads:[~2020-04-08 9:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 10:48 [PATCH for-5.0] xen: fixup RAM memory region initialization Igor Mammedov
2020-03-27 10:55 ` no-reply
2020-03-27 16:36 ` Igor Mammedov
2020-03-27 16:42 ` Paolo Bonzini
2020-03-30 16:52 ` Anthony PERARD
2020-04-02 12:29 ` Igor Mammedov
2020-04-02 13:25 ` Anthony PERARD
2020-04-02 14:30 ` Igor Mammedov
2020-04-07 11:36 ` Anthony PERARD
2020-04-08 8:45 ` Igor Mammedov [this message]
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=20200408104536.4a353c10@redhat.com \
--to=imammedo@redhat.com \
--cc=anthony.perard@citrix.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.