All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] Revert "xen-hvm: increase maxmem before calling xc_domain_populate_physmap"
Date: Tue, 16 Jun 2015 18:01:23 +0100	[thread overview]
Message-ID: <1434474083.3342.114.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1506161643110.21829@kaball.uk.xensource.com>

On Tue, 2015-06-16 at 16:51 +0100, Stefano Stabellini wrote:
> > I think reverting this change in QEMU and relevant changes in libxl
> > would be the most viable solution to solve this for this release.
> 
> Reverting this patch doesn't really solve the problem: instead of
> breaking on migration when the VM has more than 3 emulated NICs, the VM
> simply refuses to start in that case. I guess it can be considered a
> small improvement but certainly not a fix.
> 
> Given that the migration issue only happens in an "unusual corner case",
> are we really in a hurry to revert this commit and go back to the
> failure to start, even before we actually figure out what the proper fix
> is?

I don't care about migration (particularly). I care about the brokeness
in libxl which has been introduced while trying to cope with this QEMU
change.

We should revert now so that we can revert those libxl changes too and
get ourselves to a known state which doesn't have races in the memory
setting code.

It will also be much easier to move forward from a state where QEMU is
not messing with the memory limit for a domain in an uncoordinated way
and only libxl is doing so. Every QEMU release which we delay this
revert will just make it harder to find a path safe forward towards
whatever design we finally settle on.

Ian.

      parent reply	other threads:[~2015-06-16 17:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 12:55 [PATCH] Revert "xen-hvm: increase maxmem before calling xc_domain_populate_physmap" George Dunlap
2015-06-10 13:21 ` George Dunlap
2015-06-11 10:56   ` Ian Campbell
2015-06-16 11:33 ` Wei Liu
2015-06-16 15:51   ` Stefano Stabellini
2015-06-16 15:54     ` Stefano Stabellini
2015-06-16 16:58       ` Wei Liu
2015-06-16 15:56     ` George Dunlap
2015-06-16 16:49       ` Stefano Stabellini
2015-06-16 16:58         ` Ian Campbell
2015-06-16 16:57       ` Ian Campbell
2015-06-16 17:01     ` Ian Campbell [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=1434474083.3342.114.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.