From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: QEMU, MCE, unpoison memory address across reboot Date: Tue, 28 Dec 2010 11:05:49 +0200 Message-ID: <4D19A86D.5080200@redhat.com> References: <1292986371.8743.113.camel@yhuang-dev> <20101223142803.GD17819@amt.cnet> <4D1734AE.30909@redhat.com> <20101227212754.GB13518@amt.cnet> <4D199BA1.80908@redhat.com> <1293525144.22308.237.camel@yhuang-dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , Andi Kleen , Dean Nelson To: Huang Ying Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23190 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110Ab0L1JGR (ORCPT ); Tue, 28 Dec 2010 04:06:17 -0500 In-Reply-To: <1293525144.22308.237.camel@yhuang-dev> Sender: kvm-owner@vger.kernel.org List-ID: On 12/28/2010 10:32 AM, Huang Ying wrote: > 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). > It's likely just an anonymous mmap(). Even if it's not merged, it isn't the end of the world. Poisoned pages should be very rare, and nothing bad happens from having two extra VMAs. It is a little more complicated, we have to reissue MADV_MERGABLE etc, but it's better than adding new interfaces IMO. -- error compiling committee.c: too many arguments to function