Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding

[Anthony Liguori]

On 11/21/2011 11:03 AM, Peter Zijlstra wrote:
> On Mon, 2011-11-21 at 21:30 +0530, Bharata B Rao wrote:
> > In the original post of this mail thread, I proposed a way to export
> > guest RAM ranges (Guest Physical Address-GPA) and their corresponding host
> > host virtual mappings (Host Virtual Address-HVA) from QEMU (via QEMU monitor).
> > The idea was to use this GPA to HVA mappings from tools like libvirt to bind
> > 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 this from
> > libvirt.
> >
> > 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.
>
> 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.

Yes, that would be a terrible interface.

Fundamentally, the entity that should be deciding what memory should be present 
and where it should located is the kernel.  I'm fundamentally opposed to trying 
to make QEMU override the scheduler/mm by using cpu or memory pinning in QEMU.

From what I can tell about ms_mbind(), it just uses process knowledge to bind 
specific areas of memory to a memsched group and let's the kernel decide what to 
do with that knowledge.  This is exactly the type of interface that QEMU should 
be using.

QEMU should tell the kernel enough information such that the kernel can make 
good decisions.  QEMU should not be the one making the decisions.

It looks like ms_mbind() takes a flags argument which I assume is the same flags 
as mbind().  The current implementation ignores flags and just uses MPOL_BIND.

I would hope that the flags argument would only be treated as advisory by the 
kernel.

Regards,

Anthony Liguori

> 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.