From: Christoph Egger <Christoph.Egger@amd.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>, Keir Fraser <keir@xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
"Jiang, Yunhong" <yunhong.jiang@intel.com>,
"Auld, Will" <will.auld@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH] Xen/MCE: adjust for future new vMCE model
Date: Fri, 6 Jul 2012 11:12:59 +0200 [thread overview]
Message-ID: <4FF6AC1B.4070601@amd.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233528FC71@SHSMSX101.ccr.corp.intel.com>
On 07/05/12 20:38, Liu, Jinsong wrote:
> Luck, Tony wrote:
>>> I'm not sure if AMD has these 2 bits in MCG_CAP. Could you tell me
>>> where can I get
>>> AMD's *latest* open doc (something like amd architecture programmer
>>> manual)?
>>>
>>> If AMD has these 2 bits, it's safe to set them independent of host
>>> capability -- guest
>>> will just think it running on a platform w/ some events *possilbe*
>>> (though actually
>>> may never occur), hypervisor know what actually occur and has the
>>> flexibility to
>>> decide what it would like to inject to guest.
>>>
>>> This code is only used by Intel, and it's only for not blocking
>>> future vMCE, so it just do minimal necessary update.
>>
>> I think you should be very wary of creating "Franken-machines" that
>> look half AMD (according to CPUID) and half Intel (according to
>> MCG_CAP). You can look at the Linux code and check whether we always
>> make sensible decisions when presented with
>> such a system ... but you may not have that luxury with other guest
>> operating systems. My general mantra is that untested code paths have
>> bugs.
>>
>> -Tony
>
> Yes, I indeed concern AMD cpuid vs. Intel MCG_CAP. Do you suggest
> that we'd better separately provide Intel's and AMD's vMCE interface?
That is no reason to have seperate vmce_intel.c and vmce_amd.c files.
>From the last patch in function vmce_init_msr():
+ g_mcg_cap = MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM;
+
I think, this should be changed to:
g_mcg_cap = GUEST_BANK_NUM;
if (cpu_vendor == X86_VENDOR_INTEL)
g_mcg_cap |= MCG_TES_P | MCG_SER_P;
Another question:
What happens when a guest access the MSRs
0xc0000408, 0xc0000409 and 0xc000040a ?
Christoph
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2012-07-06 9:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 13:08 [PATCH] Xen/MCE: adjust for future new vMCE model Liu, Jinsong
2012-07-04 13:25 ` Christoph Egger
2012-07-04 16:08 ` Liu, Jinsong
2012-07-05 7:00 ` Jan Beulich
2012-07-05 9:18 ` Christoph Egger
2012-07-05 9:36 ` Liu, Jinsong
2012-07-05 9:53 ` Christoph Egger
2012-07-05 9:58 ` Christoph Egger
2012-07-05 10:17 ` Liu, Jinsong
2012-07-05 17:01 ` Luck, Tony
2012-07-05 18:38 ` Liu, Jinsong
2012-07-05 20:08 ` Luck, Tony
2012-07-06 9:12 ` Christoph Egger [this message]
2012-07-06 10:13 ` Jan Beulich
2012-07-04 13:37 ` Ian Campbell
2012-07-04 14:11 ` Jan Beulich
2012-07-04 13:40 ` Jan Beulich
2012-07-05 3:03 ` Liu, Jinsong
2012-07-05 6:39 ` Jan Beulich
2012-07-05 6:44 ` Ian Campbell
2012-07-05 7:02 ` Ian Campbell
2012-07-05 7:19 ` Jan Beulich
2012-07-05 7:50 ` Liu, Jinsong
2012-07-05 8:55 ` Keir Fraser
-- strict thread matches above, loose matches on Subject: below --
2012-07-05 3:30 Liu, Jinsong
2012-07-05 6:36 ` Jan Beulich
2012-07-05 7:28 ` Liu, Jinsong
2012-07-05 7:42 ` Jan Beulich
2012-07-05 6:52 ` Jan Beulich
2012-07-05 9:20 ` Liu, Jinsong
2012-07-05 10:43 ` Ian Campbell
2012-07-05 12:04 ` Liu, Jinsong
2012-07-05 17:18 ` Luck, Tony
2012-07-05 18:47 ` Liu, Jinsong
2012-07-05 11:40 ` Jan Beulich
2012-07-05 12:46 ` Liu, Jinsong
2012-07-05 13:33 ` Jan Beulich
2012-07-05 15:56 ` Liu, Jinsong
2012-07-05 16:04 ` Jan Beulich
2012-07-05 16:42 ` Liu, Jinsong
2012-07-06 8:07 ` Jan Beulich
2012-07-05 13:39 ` Christoph Egger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FF6AC1B.4070601@amd.com \
--to=christoph.egger@amd.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=jinsong.liu@intel.com \
--cc=keir@xen.org \
--cc=tony.luck@intel.com \
--cc=will.auld@intel.com \
--cc=xen-devel@lists.xensource.com \
--cc=yunhong.jiang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.