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 14:18:17 +0800
Message-ID: <1293517097.22308.228.camel@yhuang-dev>
References: <1292986371.8743.113.camel@yhuang-dev>
	 <20101223142803.GD17819@amt.cnet> <4D1734AE.30909@redhat.com>
	 <20101227212754.GB13518@amt.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Avi Kivity <avi@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	Dean Nelson <dnelson@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mga02.intel.com ([134.134.136.20]:51189 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753251Ab0L1GST (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 28 Dec 2010 01:18:19 -0500
In-Reply-To: <20101227212754.GB13518@amt.cnet>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, 2010-12-28 at 05:27 +0800, 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.

Yes.  And I think zap the page range is just the implementation detail
but semantics of MADV_DONTNEED.

But on the other hand, whether qemu_vmalloc is implemented via
posix_memalign on Linux?  If it is, we can not guarantee that
corresponding page table is zapped after qemu_vfree and qemu_vmalloc?
That is glibc implementation details.

Best Regards,
Huang Ying