WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler

To: "JBeulich@xxxxxxxx" <JBeulich@xxxxxxxx>, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Sat, 8 Oct 2011 17:05:05 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "keir.xen@xxxxxxxxx" <keir.xen@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 08 Oct 2011 02:06:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E8EC9940200007800059E47@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BC00F5384FCFC9499AF06F92E8B78A9E263B557B77@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E84ADF70200007800058882@xxxxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D306597312D2366A9B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E858AF30200007800058A64@xxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F02@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E8592A60200007800058AD4@xxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F40@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E859D7F0200007800058B39@xxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F7C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E85B09F0200007800058B7B@xxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E263B557F90@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E264E34D85F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E8EC9940200007800059E47@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcyExJRvS8PfpDNWQViD7Uz0eTT9JgA1ERxw
Thread-topic: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Friday, October 07, 2011 3:43 PM
> To: Liu, Jinsong; Jiang, Yunhong
> Cc: keir.xen@xxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] X86 MCE: Add SRAR handler
> 
> >>> On 06.10.11 at 20:40, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> > Liu, Jinsong wrote:
> >> Liu, Jinsong wrote:
> >>> Jan Beulich wrote:
> >>>>>>> On 30.09.11 at 11:42, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
> >>>>>>> wrote:
> >>>>> Jan Beulich wrote:
> >>>>>>>>> On 30.09.11 at 10:21, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
> >>>>>>>>> wrote:
> >>>>>>> Executing guest code will not satisfy the check
> >>>>>>> if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
>       return
> >>>>>>> -1; so it would not panic system.
> >>>>>>
> >>>>>> Exactly. But it should when the prefetch was to hypervisor code.
> >>>>>>
> >>>>>
> >>>>> Wouldn't processor refresh instruction prefetch queue under such
> >>>>> case?
> >>>>
> >>>> That's a question that you are better positioned to answer than me.
> >>>> But the SRAR errors being a sub-category of uncorrected errors I
> >>>> would think it can't be that simple.
> >>>>
> >>>
> >>> Hmm, I will check this question internally first.
> >>> BTW, we would have 7 days holiday (1/10 ~ 7/10), so email reply
> >>> maybe some slow.
> >>>
> >>> Thanks,
> >>> Jinsong
> >>
> >> Ah, just think our talking context: the prefetched instruction would
> >> have been flushed since we now at mce exception context. So I think
> >> no need to overkill here, just let guest handle it --> who own, who
> >> take.
> >>
> >> Thanks,
> >> Jinsong
> >
> > Jan,
> >
> > Do you think following is OK?
> >
> > if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
> >     return -1;
> 
> That's what we have currently, and as I said earlier I don't think using
> the result of guest_mode() for any decision is valid when the EIPV bit
> is clear.

guest_mode() should be ok to be used together with RIPV, since RIPV is
talking about the RIP in the stack.

Thanks
--jyh

> 
> Jan
> 
> > Thanks,
> > Jinsong
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel