From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Handle vma regions with no backing page (v2) Date: Wed, 30 Apr 2008 01:52:30 +0300 Message-ID: <4817A6AE.2090806@qumranet.com> References: <1209496160-20482-1-git-send-email-aliguori@us.ibm.com> <48179E8D.4070407@qumranet.com> <4817A06C.5000503@codemonkey.ws> <4817A44D.5080808@qumranet.com> <4817A682.3090308@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Carsten Otte , Andrea Arcangeli , Hollis Blanchard , kvm-devel@lists.sourceforge.net, Ben-Ami Yassour , "Zhang, Xiantao" To: Anthony Liguori Return-path: In-Reply-To: <4817A682.3090308@us.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > Avi Kivity wrote: >> It depends on what's going on? Does a page table point to mmio? Or >> the glommerclock? >> >> Not sure there is a single answer. >> >>> Perhaps we should be replacing consumers of gfn_to_page() with >>> copy_to_user() instead? >> >> Indeed we should. The problem is access in atomic contexts. It's >> easy to detect failure, but not always easy to handle it. > > So I think we should replace it with a rate limited printk and > returning bad_page. That way the guest can't exploit it and we'll > still hopefully get printk()s to track down instances of things going > bad. > Agreed. Add a stacktrace so we can see what causes the badness. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone