From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC PATCH] Exporting Guest RAM information for
 NUMA binding
Date: Mon, 21 Nov 2011 18:03:00 +0100
Message-ID: <1321894980.28118.16.camel@twins>
References: <20111029184502.GH11038@in.ibm.com>
	<7816C401-9BE5-48A9-8BA9-4CDAD1B39FC8@suse.de>
	<20111108173304.GA14486@sequoia.sous-sol.org>
	<20111121150054.GA3602@in.ibm.com> <1321889126.28118.5.camel@twins>
	<20111121160001.GB3602@in.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Andrea Arcangeli <aarcange@redhat.com>, kvm list <kvm@vger.kernel.org>,
	Alexander Graf <agraf@suse.de>,
	qemu-devel Developers <qemu-devel@nongnu.org>,
	Chris Wright <chrisw@sous-sol.org>, dipankar@in.ibm.com,
	Vaidyanathan S <svaidy@in.ibm.com>
To: bharata@linux.vnet.ibm.com
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <20111121160001.GB3602@in.ibm.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On Mon, 2011-11-21 at 21:30 +0530, Bharata B Rao wrote:
>=20
> In the original post of this mail thread, I proposed a way to export
> guest RAM ranges (Guest Physical Address-GPA) and their corresponding hos=
t
> host virtual mappings (Host Virtual Address-HVA) from QEMU (via QEMU moni=
tor).
> The idea was to use this GPA to HVA mappings from tools like libvirt to b=
ind
> specific parts of the guest RAM to different host nodes. This needed an
> extension to existing mbind() to allow binding memory of a process(QEMU) =
from a
> different process(libvirt). This was needed since we wanted to do all thi=
s from
> libvirt.
>=20
> Hence I was coming from that background when I asked for extending
> ms_mbind() to take a tid parameter. If QEMU community thinks that NUMA
> binding should all be done from outside of QEMU, it is needed, otherwise
> what you have should be sufficient.=20

That's just retarded, and no you won't get such extentions. Poking at
another process's virtual address space is just daft. Esp. if there's no
actual reason for it.

Furthermore, it would make libvirt a required part of qemu, and since I
don't think I've ever use libvirt that's another reason to object, I
don't need that stinking mess.