Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933331AbYAYIsh (ORCPT ); Fri, 25 Jan 2008 03:48:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762005AbYAYIix (ORCPT ); Fri, 25 Jan 2008 03:38:53 -0500 Received: from smtp104.mail.mud.yahoo.com ([209.191.85.214]:36069 "HELO smtp104.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1758180AbYAYIiu (ORCPT ); Fri, 25 Jan 2008 03:38:50 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=EKjyRm60mNwNtRrhLxYGh3snEm1Dv5/4K4nvN7mY+EVodcsNgU2Xp1qwOSNqbDeYKcXfMWBG9u7JpJut6FCl1thiypRPIQbshdzaj5PYH9W3Xbo5wz/lYdmclR8EHTna2AhsGmzijo8Jl1nMoWKWMVUd8frwc0U7v3OoZs4gz9M= ; X-YMail-OSG: I7.dZNoVM1l8GqNZaGQudC7f7buPEIeTIANe26dqDAG7MJCYcow9_BLYWP2tENDi.2F29bhL_A-- X-Yahoo-Newman-Property: ymail-3 From: Nick Piggin To: "Jan Beulich" Subject: Re: [PATCH UPDATE] x86: ignore spurious faults Date: Fri, 25 Jan 2008 19:38:38 +1100 User-Agent: KMail/1.9.5 Cc: "Keir Fraser" , "Jeremy Fitzhardinge" , "Ingo Molnar" , "Harvey Harrison" , "Matt Mackall" , "Andi Kleen" , "Linux Kernel Mailing List" References: <47992CB2.8050606@goop.org> <4799A8A6.76E4.0078.0@novell.com> In-Reply-To: <4799A8A6.76E4.0078.0@novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801251938.39231.nickpiggin@yahoo.com.au> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 803 Lines: 18 On Friday 25 January 2008 19:15, Jan Beulich wrote: > Actually, another thought: permitting (and handling) spurious faults for > kernel mappings conflicts with NMI handling, i.e. great care would be > needed to ensure the NMI path cannot touch any such mapping. So > even the present Xen/Linux Dom0 implementation may have some > (perhaps unlikely) problems here, and it would get worse if we added > e.g. a virtual watchdog NMI (something I am considering, which would > then extend the problem to DomU-s). Can you explain how they conflict? Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/