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
--
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
