From mboxrd@z Thu Jan  1 00:00:00 1970
From: Huang Ying <ying.huang@intel.com>
Subject: Re: QEMU, MCE, unpoison memory address across reboot
Date: Tue, 28 Dec 2010 16:32:24 +0800
Message-ID: <1293525144.22308.237.camel@yhuang-dev>
References: <1292986371.8743.113.camel@yhuang-dev>
	 <20101223142803.GD17819@amt.cnet> <4D1734AE.30909@redhat.com>
	 <20101227212754.GB13518@amt.cnet>  <4D199BA1.80908@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	Dean Nelson <dnelson@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mga14.intel.com ([143.182.124.37]:31108 "EHLO mga14.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751385Ab0L1Ic1 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 28 Dec 2010 03:32:27 -0500
In-Reply-To: <4D199BA1.80908@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, 2010-12-28 at 16:11 +0800, Avi Kivity wrote:
> On 12/27/2010 11:27 PM, Marcelo Tosatti wrote:
> > On Sun, Dec 26, 2010 at 02:27:26PM +0200, Avi Kivity wrote:
> > >  >>   +static void kvm_unpoison_all(void *param)
> > >  >>   +{
> > >  >>   +    HWPoisonPage *page, *next_page;
> > >  >>   +    unsigned long address;
> > >  >>   +    KVMState *s = param;
> > >  >>   +
> > >  >>   +    QLIST_FOREACH_SAFE(page,&hwpoison_page_list, list, next_page) {
> > >  >>   +        address = (unsigned long)page->vaddr;
> > >  >>   +        QLIST_REMOVE(page, list);
> > >  >>   +        kvm_vm_ioctl(s, KVM_UNPOISON_ADDRESS, address);
> > >  >>   +        qemu_free(page);
> > >  >>   +    }
> > >  >>   +}
> > >  >
> > >  >Can't you free and reallocate all guest memory instead, on reboot, if
> > >  >there's a hwpoisoned page? Then you don't need this interface.
> > >  >
> > >
> > >  Alternatively, MADV_DONTNEED?  We already use it for ballooning.
> >
> > Does not work for hugetlbfs.
> >
> 
> True.  We can munmap() the page (extending it to the huge page size in 
> effect), and then mmap() it back in.  The kernel should merge the new 
> vma with its neighbors.

To merge the new vma with its neighbors, we need all information about
the original mmap (when doing allocating).  It appears that some
information is hided in glibc (posix_memalign).

Best Regards,
Huang Ying