From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Subject: Re: [patch uq/master 7/8] MCE: Relay UCR MCE to guest
Date: Wed, 06 Oct 2010 10:58:36 +0900
Message-ID: <4CABD7CC.6030909@jp.fujitsu.com>
References: <20101004185447.891324545@redhat.com> <20101004185715.167557459@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
	Huang Ying <ying.huang@intel.com>,
	Dean Nelson <dnelson@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:39583 "EHLO
	fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754264Ab0JFB7E (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 5 Oct 2010 21:59:04 -0400
Received: from m6.gw.fujitsu.co.jp ([10.0.50.76])
	by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o961x1BR007072
	for <kvm@vger.kernel.org> (envelope-from seto.hidetoshi@jp.fujitsu.com);
	Wed, 6 Oct 2010 10:59:02 +0900
Received: from smail (m6 [127.0.0.1])
	by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id AE13E45DE53
	for <kvm@vger.kernel.org>; Wed,  6 Oct 2010 10:59:01 +0900 (JST)
Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96])
	by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 94C8645DE51
	for <kvm@vger.kernel.org>; Wed,  6 Oct 2010 10:59:01 +0900 (JST)
Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 6135C1DB8014
	for <kvm@vger.kernel.org>; Wed,  6 Oct 2010 10:59:01 +0900 (JST)
Received: from m107.s.css.fujitsu.com (m107.s.css.fujitsu.com [10.249.87.107])
	by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 10C581DB8012
	for <kvm@vger.kernel.org>; Wed,  6 Oct 2010 10:59:01 +0900 (JST)
In-Reply-To: <20101004185715.167557459@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

I got some more question:

(2010/10/05 3:54), Marcelo Tosatti wrote:
> Index: qemu/target-i386/cpu.h
> ===================================================================
> --- qemu.orig/target-i386/cpu.h
> +++ qemu/target-i386/cpu.h
> @@ -250,16 +250,32 @@
>  #define PG_ERROR_RSVD_MASK 0x08
>  #define PG_ERROR_I_D_MASK  0x10
>  
> -#define MCG_CTL_P	(1UL<<8)   /* MCG_CAP register available */
> +#define MCG_CTL_P	(1ULL<<8)   /* MCG_CAP register available */
> +#define MCG_SER_P	(1ULL<<24) /* MCA recovery/new status bits */
>  
> -#define MCE_CAP_DEF	MCG_CTL_P
> +#define MCE_CAP_DEF	(MCG_CTL_P|MCG_SER_P)
>  #define MCE_BANKS_DEF	10
>  

It seems that current kvm doesn't support SER_P, so injecting SRAO
to guest will mean that guest receives VAL|UC|!PCC and RIPV event
from virtual processor that doesn't have SER_P.

I think most OSes don't expect that it can receives MCE with !PCC
on traditional x86 processor without SER_P.

Q1: Is it safe to expect that guests can handle such !PCC event?
Q2: What is the expected behavior on the guest?
Q3: What happen if guest reboots itself in response to the MCE?


Thanks,
H.Seto