From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42714 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pn4yH-0008W4-4r for qemu-devel@nongnu.org; Wed, 09 Feb 2011 03:00:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pn4yF-0007Ky-J6 for qemu-devel@nongnu.org; Wed, 09 Feb 2011 03:00:17 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:40415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pn4yF-0007Kg-8J for qemu-devel@nongnu.org; Wed, 09 Feb 2011 03:00:15 -0500 Message-ID: <4D52498D.9060706@web.de> Date: Wed, 09 Feb 2011 09:00:13 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1297220431.5180.15.camel@yhuang-dev> In-Reply-To: <1297220431.5180.15.camel@yhuang-dev> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8D2AFF94EDFCD7B330FE253" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH uq/master -v2 2/2] KVM, MCE, unpoison memory address across reboot List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Huang Ying Cc: "kvm@vger.kernel.org" , Dean Nelson , Marcelo Tosatti , "qemu-devel@nongnu.org" , Anthony Liguori , Andi Kleen , Avi Kivity This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8D2AFF94EDFCD7B330FE253 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-02-09 04:00, Huang Ying wrote: > In Linux kernel HWPoison processing implementation, the virtual > address in processes mapping the error physical memory page is marked > as HWPoison. So that, the further accessing to the virtual > address will kill corresponding processes with SIGBUS. >=20 > If the error physical memory page is used by a KVM guest, the SIGBUS > will be sent to QEMU, and QEMU will simulate a MCE to report that > memory error to the guest OS. If the guest OS can not recover from > the error (for example, the page is accessed by kernel code), guest OS > will reboot the system. But because the underlying host virtual > address backing the guest physical memory is still poisoned, if the > guest system accesses the corresponding guest physical memory even > after rebooting, the SIGBUS will still be sent to QEMU and MCE will be > simulated. That is, guest system can not recover via rebooting. Yeah, saw this already during my test... >=20 > In fact, across rebooting, the contents of guest physical memory page > need not to be kept. We can allocate a new host physical page to > back the corresponding guest physical address. I just wondering what would be architecturally suboptimal if we simply remapped on SIGBUS directly. Would save us at least the bookkeeping. >=20 > This patch fixes this issue in QEMU-KVM via calling qemu_ram_remap() > to clear the corresponding page table entry, so that make it possible > to allocate a new page to recover the issue. >=20 > Signed-off-by: Huang Ying > --- > target-i386/kvm.c | 39 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) >=20 > --- a/target-i386/kvm.c > +++ b/target-i386/kvm.c > @@ -508,6 +508,42 @@ static int kvm_get_supported_msrs(KVMSta > return ret; > } > =20 > +struct HWPoisonPage; > +typedef struct HWPoisonPage HWPoisonPage; > +struct HWPoisonPage > +{ > + ram_addr_t ram_addr; > + QLIST_ENTRY(HWPoisonPage) list; > +}; > + > +static QLIST_HEAD(hwpoison_page_list, HWPoisonPage) hwpoison_page_list= =3D > + QLIST_HEAD_INITIALIZER(hwpoison_page_list); > + > +static void kvm_unpoison_all(void *param) > +{ > + HWPoisonPage *page, *next_page; > + > + QLIST_FOREACH_SAFE(page, &hwpoison_page_list, list, next_page) { > + QLIST_REMOVE(page, list); > + qemu_ram_remap(page->ram_addr, TARGET_PAGE_SIZE); > + qemu_free(page); > + } > +} > + > +static void kvm_hwpoison_page_add(ram_addr_t ram_addr) > +{ > + HWPoisonPage *page; > + > + QLIST_FOREACH(page, &hwpoison_page_list, list) { > + if (page->ram_addr =3D=3D ram_addr) > + return; > + } > + > + page =3D qemu_malloc(sizeof(HWPoisonPage)); > + page->ram_addr =3D ram_addr; > + QLIST_INSERT_HEAD(&hwpoison_page_list, page, list); > +} > + > int kvm_arch_init(KVMState *s) > { > uint64_t identity_base =3D 0xfffbc000; > @@ -556,6 +592,7 @@ int kvm_arch_init(KVMState *s) > fprintf(stderr, "e820_add_entry() table is full\n"); > return ret; > } > + qemu_register_reset(kvm_unpoison_all, NULL); > =20 > return 0; > } > @@ -1882,6 +1919,7 @@ int kvm_arch_on_sigbus_vcpu(CPUState *en > hardware_memory_error(); > } > } > + kvm_hwpoison_page_add(ram_addr); > =20 > if (code =3D=3D BUS_MCEERR_AR) { > /* Fake an Intel architectural Data Load SRAR UCR */ > @@ -1926,6 +1964,7 @@ int kvm_arch_on_sigbus(int code, void *a > "QEMU itself instead of guest system!: %p\n", addr= ); > return 0; > } > + kvm_hwpoison_page_add(ram_addr); > kvm_mce_inj_srao_memscrub2(first_cpu, paddr); > } else > #endif >=20 >=20 Looks fine otherwise. Unless that simplification makes sense, I could offer to include this into my MCE rework (there is some minor conflict). If all goes well, that series should be posted during this week. Jan --------------enigD8D2AFF94EDFCD7B330FE253 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SSY0ACgkQitSsb3rl5xScRQCgmkc9AxTch/uV+uWbmNTX9c+J rwwAmwfMRPjY9nzyQWNa4m5IeXeOSJLM =hGZz -----END PGP SIGNATURE----- --------------enigD8D2AFF94EDFCD7B330FE253--