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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
