[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EDBAF1C.3050308@redhat.com>
Date: Sun, 04 Dec 2011 19:34:20 +0200
From: Avi Kivity <avi@...hat.com>
To: Sasha Levin <levinsasha928@...il.com>
CC: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>,
linux-kernel@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>, kvm@...r.kernel.org,
Takuya Yoshikawa <takuya.yoshikawa@...il.com>
Subject: Re: [PATCH] KVM: Veirfy memory slot only for readability
On 12/04/2011 07:29 PM, Sasha Levin wrote:
> On Sun, 2011-12-04 at 18:53 +0200, Avi Kivity wrote:
> > On 12/02/2011 07:46 AM, Sasha Levin wrote:
> > > > Do you want to create read only memory slots for kvm tool?
> > >
> > > What KVM tool currently does is copy the kernel into guest memory and
> > > run it from there. An idea raised recently was instead of copying it we
> > > should mmap it into the memory to reduce footprint.
> > >
> > > This is why I'm looking into adding a read only memory slot. The KVM
> > > code doesn't have to know it's read only.
> >
> > The kernel will patch itself very early. You need to use MAP_PRIVATE
> > (and thus have a read/write area). It will be interesting to see what
> > fraction of the memory is modified.
> >
> > Note that mapping will remove benefits like huge page support, and that
> > you can get page sharing by using ksm. Still, it's interesting to see
> > where this goes.
>
> Why would I lose hugepage if the kernel gets it's own memory slot?
(transparent) hugepages only work on anonymous memory. Hopefully later
it will be extended to work on mapped memory as well.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists