[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 2/3] pc & q35: Add new machine opt max-ram-below-4g



On 06/10/14 03:36, Gerd Hoffmann wrote:
   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.


I agree.

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 is happening as far as I know and does not directly impact this
patch set.

   That should
also make qemu use the memory layout expected by old xen.

Currently xen just ignores the memory layout that QEMU sets up
and does it's own way.  So no, this does not make QEMU use the
memory layout expected by old xen.

Patch #1 (xen-hvm: Fix xen_hvm_init)
is all about letting the rest of QEMU know about the changed
memory layout.  This patch and patch #3 (xen-hvm: Pass is_default
to xen_hvm_init) are in addition to allowing QEMU to have more
memory layouts but also allows xen to have more memory layouts
like a gigabyte aligned one.

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 ...

Yes

   -Don Slutz


cheers,
   Gerd




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.