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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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