From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: QEMU bumping memory bug analysis Date: Tue, 16 Jun 2015 17:44:52 +0100 Message-ID: References: <20150605164354.GK29102@zion.uk.xensource.com> <1433530180.3342.17.camel@citrix.com> <1433765498.7108.480.camel@citrix.com> <5575A4C5.5070702@eu.citrix.com> <5575AE47.3020208@one.verizon.com> <5575B6D0.8010407@eu.citrix.com> <5576CC19.4070300@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5576CC19.4070300@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Don Slutz , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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.