lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 17 May 2012 06:30:45 +0000
From:	"Hao, Xudong" <xudong.hao@...el.com>
To:	Avi Kivity <avi@...hat.com>,
	Takuya Yoshikawa <takuya.yoshikawa@...il.com>
CC:	Xudong Hao <xudong.hao@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Shan, Haitao" <haitao.shan@...el.com>,
	"Zhang, Xiantao" <xiantao.zhang@...el.com>
Subject: RE: [PATCH 0/4] KVM: Enable EPT access bit feature

> -----Original Message-----
> From: Avi Kivity [mailto:avi@...hat.com]
> Sent: Wednesday, May 16, 2012 9:44 PM
> To: Takuya Yoshikawa
> Cc: Xudong Hao; kvm@...r.kernel.org; linux-kernel@...r.kernel.org; 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@...hat.com> 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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ