Re: [Xen-devel] QEMU bumping memory bug analysis

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 9 Jun 2015, George Dunlap wrote:
> On 06/09/2015 11:14 AM, Stefano Stabellini wrote:
> > On Mon, 8 Jun 2015, George Dunlap wrote:
> >> I think that qemu needs to tell libxl how much memory it is using for
> >> all of its needs -- including option ROMs.  (See my example below.)  For
> >> older qemus we can just make some assumptions like we always have.
> > 
> > I'll just note that I have still not seen any evidence that telling
> > libxl would improve things. It seems to me that we are just adding one
> > more layer of indirection just to solve the migration issue elsewhere.
> > I haven't seen convincing examples that things would be better by telling
> > libxl yet, except that we would be able to fix the migration problem.
> 
> So from a migration perspective, I agree there's not much difference
> between "libxl reads max_pages from Xen, inserts it into the migration
> stream, and sets it again on the other side" and "libxl has global
> knowledge of what max_pages should be, inserts it into the migration
> stream, and sets it again on the other side".
> 
> Improvements of having it in libxl:
> 
> 1. libxl is not an external interface; we can change and improve things
> as we go along.

Actually libxl is an external interface, did you mean libxc?


> Whatever we put in qemu we have to support indefinitely.

The maxmem call is already in QEMU :-)


> 2. We can begin to solve the "where is the memory" mess that is the
> current state of things.
>
> 3. In particular, we could conceivably actually change the interface to
> be consistent, so that "memory" means "the maximum amount of memory used
> by the guest including all overhead", rather than the random who knows
> what we have now. 

That's it, I agree.  But the issue is that we don't have a solution or
even the design of a solution. If we had, and the plan included
reverting the QEMU commit, then fine, let's do it.


> This will be impossible if we do it in qemu.
>
> Having more than one place change max_pages would be poor design even if
> we were still packaging everything together in the same release.  Having
> an external entity with which we must be backwards-compatible change
> max_pages it is just a bad idea and always was.

I disagree, if it was such an obvious design mistake, more people would
have picked up on it immediately when the patch was posted the first
time around.  This is blurry terrain at best.


> > When I committed it, I didn't
> > do it without thinking. I don't think that libxl should be in the middle
> > of this, because I don't think it has anything to add.
> 
> Just to be clear, nobody thinks you did (at least, as far as I know).
> The problem is that all of us are so specialized: some people work
> almost entirely within qemu, others in the kernel, others in the
> toolstack, others in Xen.  It's just natural for people who work mainly
> within one component to look at the problem from a particular
> perspective.  But it causes exactly this sort of problem, where the left
> hand doesn't know what the right hand is doing, and the overall system
> is really uncoordinated.

That is true.

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