From: Gerd Hoffmann <kraxel@redhat.com>
To: Don Slutz <dslutz@verizon.com>
Cc: xen-devel@lists.xensource.com,
"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, "Anthony Liguori" <aliguori@amazon.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v5 2/3] pc & q35: Add new machine opt max-ram-below-4g
Date: Tue, 10 Jun 2014 09:36:41 +0200 [thread overview]
Message-ID: <1402385801.8739.13.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <53960750.3050300@terremark.com>
Hi,
> > So instead of default 0, it would be preferable to set the default to the
> > actual value, and let user override it.
> >
> > Or if that's too hard, set max_ram_below_4g instead of setting
> > gigabyte_align. gigabyte_align switches everywhere is messy
> > enough, adding max_ram_below_4g into mix is just too messy.
> >
>
> I do not see a way to encode the default since for QEMU 2.0 it depends on the specified ram size:
>
> > This is intentional.
>
> > If we can fit all ram into low memory, because it is less than 3.5G,
> > we'll do that (pc machine type, q35 numbers are different but logic is
> > the same). This way 32bit (+non-PAE) guests can continue to have up to
> > 3.5G memory.
>
> > If we can't fit all ram into low memory (thus the guest should be able
> > to access ram above 4G anyway), then we'll cut off at a gigabyte
> > boundary (3G for pc machine type). This way our ram is nicely
> > gigabyte-aligned and we can get best performance benefits from huge
> > pages.
>
> > The size of the pci hole changing in the second case is only a side
> > effect, it's not the main reason for the change.
>
> > cheers,
> > Gerd
>
> So migration of a QEMU 2.0 pc to QEMU 2.1 without gigabyte_align would require the user
> to specify the correct value of max-ram-below-4g.
You are expected to use the same machine type on both ends for live
migration. That is the whole point why the gigabyte alignment logic is
activated for new machine types only: Just -M pc-<version> should be
enough to make the machine config and the vmstate wire format compatible
even with different qemu versions on both ends, without requiring the
user manually specifying obscure parameters.
> When you add xen into the mix I do not see a way to get right of gigabyte_align.
>
> You have 3 cases:
>
> 1) old xen (without max-ram-below-4g), QEMU 2.1 or later.
> Will expect that QEMU acts as if max-ram-below-4g=3.75G was specified.
> I.E. gigabyte_align is ignored. Note: xen 4.4 asks for "pc,accel=xen" in some cases.
IMO xen should use a versioned machine type to make live migration more
reliable. IIRC this was discussed anyway for other reasons (see
xen-platform-pci discussions, picking pc-i440fx-1.6 IIRC). That should
also make qemu use the memory layout expected by old xen.
> 3) new xen (with max-ram-below-4g), QEMU 2.1 or later.
> Expects that max-ram-below-4g works.
Newer xen versions can switch to a newer machine type, once it knows how
to deal with the changes: other memory layout, new config switches,
whatever else might have changed ...
cheers,
Gerd
next prev parent reply other threads:[~2014-06-10 7:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 17:52 [Qemu-devel] [PATCH v5 0/3] Add max-ram-below-4g (was Add pci_hole_min_size machine option) Don Slutz
2014-06-06 17:52 ` [Qemu-devel] [PATCH v5 1/3] xen-hvm: Fix xen_hvm_init() to adjust pc memory layout Don Slutz
2014-06-06 17:52 ` [Qemu-devel] [PATCH v5 2/3] pc & q35: Add new machine opt max-ram-below-4g Don Slutz
2014-06-08 15:40 ` Michael S. Tsirkin
2014-06-09 14:20 ` Don Slutz
2014-06-09 14:38 ` Michael S. Tsirkin
2014-06-09 15:10 ` Marcel Apfelbaum
2014-06-09 15:37 ` Igor Mammedov
2014-06-09 17:33 ` Marcel Apfelbaum
2014-06-09 20:03 ` Don Slutz
2014-06-09 19:13 ` Don Slutz
2014-06-10 7:36 ` Gerd Hoffmann [this message]
2014-06-17 17:51 ` Don Slutz
2014-06-18 9:52 ` Gerd Hoffmann
2014-06-17 18:22 ` Michael S. Tsirkin
2014-06-17 18:44 ` Don Slutz
2014-06-17 19:43 ` Michael S. Tsirkin
2014-06-17 20:05 ` Michael S. Tsirkin
2014-06-17 20:08 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2014-06-17 20:17 ` Michael S. Tsirkin
2014-06-18 13:28 ` Slutz, Donald Christopher
2014-06-17 20:35 ` Pasi Kärkkäinen
2014-06-06 17:52 ` [Qemu-devel] [PATCH v5 3/3] xen-hvm: Pass is_default to xen_hvm_init Don Slutz
2014-06-08 15:24 ` Michael S. Tsirkin
2014-06-09 14:25 ` Don Slutz
2014-06-09 14:39 ` Michael S. Tsirkin
2014-06-08 15:42 ` Michael S. Tsirkin
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=1402385801.8739.13.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=dslutz@verizon.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).