RE: [PATCH 0/4] KVM: Enable EPT access bit feature

[Hao, Xudong]

> -----Original Message-----
> From: Avi Kivity [mailto:avi@xxxxxxxxxx]
> Sent: Wednesday, May 16, 2012 9:44 PM
> To: Takuya Yoshikawa
> Cc: Xudong Hao; kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Shan,
> Haitao; Zhang, Xiantao; Hao, Xudong
> Subject: Re: [PATCH 0/4] KVM: Enable EPT access bit feature
> 
> On 05/16/2012 04:35 PM, Takuya Yoshikawa wrote:
> > On Wed, 16 May 2012 12:21:53 +0300
> > Avi Kivity <avi@xxxxxxxxxx> wrote:
> >
> > > On 05/16/2012 04:04 AM, Xudong Hao wrote:
> > > > EPT A/D bits enable VMMs to efficiently implement memory management
> and page classification algorithms to optimize VM memory operations such as
> de-fragmentation, paging, live-migration, and check-pointing.
> > > >
> > > > The series of patches enable the EPT access bit in KVM.
> > > >
> > > > PATCH 1: Add EPT A/D bits definition.
> > > > PATCH 2: Add kernel parameter to control EPT A/D bits support, the
> feature is on by default.
> > > > PATCH 3: Enable EPT A/D bits if supported by turning on relevant bit in
> EPTP.
> > > > PATCH 4: Enabling Access bit when doing memory swapping.
> > > >
> > >
> > > Minor comment on patch 2, but otherwise looks good.
> >
> > Except for being white space damaged and based on old kvm.git?
> 
> Ugh, I didn't notice that.  Xudong, please rebase on kvm.git 'next', and
> repost using git send-email.
> 

Oh, my patch is based on 'master' branch, I saw some changes in mmu.c by Takuya which will conflict patch 4, I'll rebase on 'next' branch.
Anyway, I'll send whole four patches as v2 of 'next' branch.

> > BTW, we can use this for dirty logging as you suggested.
> >
> > Although we need to traverse each spte from rmap
> 
> That should be cheap.  Also, we might be able to cheat for direct-mapped
> pages: if all pages in a 2M area are mapped just once, in a
> direct-mapped page, we can skip rmap and iterate over the page
> directly.  We can store this hint in lpage_info.
> 
> There's a chance that this optimization will gain nothing since the
> processor may be able to unroll the loop and hide the rmap costs for the
> next spte behind the atomic access cost for the current spte.
> 
> > and sync with dirty
> > bitmap, I think it will work well by using with range based GET_DIRTY_LOG
> > to restrict the cost for one call.
> 
> I'm in favour of that as well (even more, since the install base will be
> dominated by non-AD-capable hosts for some time).
> 
> --
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/