[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Re: [PATCH] Add huge page support to libvirt, v2..

On Mon, 2009-07-27 at 22:55 +0100, Daniel P. Berrange wrote:
> On Thu, Jul 23, 2009 at 09:00:18PM -0400, john cooper wrote:
> > I've incorporated feedback received on the
> > prior version into the patch below.
> > 
> > The host mount point for hugetlbfs is queried by
> > default from /proc/mounts unless overridden in
> > qemu.conf via:
> > 
> >     hugepage_mount = "<path_to_mount_point>"
> > 
> > This should make the concern of establishing
> > a mount point path convention a non-issue for
> > the general case while still allowing the same
> > to be deterministically set if needed.
> In light of what Chris said about extended attribute support
> for SELinux I think we, sadly, have no choice by to mount
> a new instance of hugetlbfs per VM, labelled with the context
> of that VM.

I haven't played with hugetlbfs much, so let me make sure I understand
the issue:

  -) With --mempath, qemu creates a file under the supplied directory 
     and mmap()s it, using the mapped region for guest memory

  -) Because the directory is under hugetlbfs, that memory is huge page 

  -) Guest memory can be read by reading this file

  -) The file is owned by the uid of the qemu process, so any other 
     processes with that uid can access guest memory

  -) If we could label the file, we could use policy to prevent qemu 
     processes from accessing each other's files

  -) We can't, so the alternative is to use a separate hugetlbfs mount 
     for each guest, each with a different label - each mount will only 
     contain the file for that guest, and only be accessible by that 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]