From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: QEMU, MCE, unpoison memory address across reboot Date: Mon, 27 Dec 2010 19:27:15 -0200 Message-ID: <20101227212715.GA13518@amt.cnet> References: <1292986371.8743.113.camel@yhuang-dev> <20101223142803.GD17819@amt.cnet> <1293161437.22308.170.camel@yhuang-dev> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , "kvm@vger.kernel.org" , Andi Kleen , Dean Nelson To: Huang Ying Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9724 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495Ab0L0VaF (ORCPT ); Mon, 27 Dec 2010 16:30:05 -0500 Content-Disposition: inline In-Reply-To: <1293161437.22308.170.camel@yhuang-dev> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Dec 24, 2010 at 11:30:37AM +0800, Huang Ying wrote: > On Thu, 2010-12-23 at 22:28 +0800, Marcelo Tosatti wrote: > > 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. > > Consider about this method. It seems that some guest RAMs are not > allocated in qemu_ram_alloc_from_ptr(), that is, host parameter is > allocated elsewhere and passed in. I found two: > > - assigned_dev_register_regions() in hw/device-assignment.c > - create_shared_memory_BAR() and ivshmem_read() in hw/ivshmem.c > > There is no general method to reallocate these memory so far. We may > need a flag in struct RAMBlock to track these memory, and ignore them > during reallocation. But if there are hwpoisoned pages in these memory, > we can not recover. Do you think that is OK? Yes, these are not guest RAM so there should be no MCE for them.