linux-kernel - Re: [RFC] respect the referenced bit of KVM guest pages?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090805163537.GG23385@random.random>
Date:	Wed, 5 Aug 2009 18:35:37 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Rik van Riel <riel@...hat.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	"Dike, Jeffrey G" <jeffrey.g.dike@...el.com>,
	"Yu, Wilfred" <wilfred.yu@...el.com>,
	"Kleen, Andi" <andi.kleen@...el.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC] respect the referenced bit of KVM guest pages?

On Wed, Aug 05, 2009 at 06:25:28PM +0300, Avi Kivity wrote:
> On 08/05/2009 06:15 PM, Rik van Riel wrote:
> > Avi Kivity wrote:
> >
> >>> If so, we could unmap them when they get moved from the
> >>> active to the inactive list, and soft fault them back in
> >>> on access, emulating the referenced bit for EPT pages and
> >>> making page replacement on them work like it should.
> >>
> >> It should be easy to implement via the mmu notifier callback: when 
> >> the mm calls clear_flush_young(), mark it as young, and unmap it from 
> >> the EPT pagetable.
> >
> > You mean "mark it as old"?
> 
> I meant 'return young, and drop it from the EPT pagetable'.
> 
> If we use the present bit as a replacement for the accessed bit, present 
> means young, and clear_flush_young means "if present, return young and 
> unmap, otherwise return old'.

This is the only way to provide accurate information, and it's still a
minor fault so not very different than return young first time around
and old second time around without invalidating the spte... but the
only reason I like it more is that it is done at the right time, like
for the ptes, so probably it's best to implement it this way to ensure
total fairness of the VM regardless if it's guest or qemu-kvm touching
the virtual memory.
--
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/