From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbdHHKBw (ORCPT ); Tue, 8 Aug 2017 06:01:52 -0400 Received: from smtp.eu.citrix.com ([185.25.65.24]:34861 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751921AbdHHKBv (ORCPT ); Tue, 8 Aug 2017 06:01:51 -0400 X-IronPort-AV: E=Sophos;i="5.41,342,1498521600"; d="scan'208";a="50650437" Subject: Re: [Xen-devel] [PATCH v3] xen: get rid of paravirt op adjust_exception_frame To: Juergen Gross , Boris Ostrovsky , , , CC: , , , References: <20170803154548.13817-1-jgross@suse.com> From: Andrew Cooper Message-ID: <522caac2-fbf2-09f6-e21f-df26b7261c3d@citrix.com> Date: Tue, 8 Aug 2017 11:01:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/08/17 08:02, Juergen Gross wrote: > On 07/08/17 22:56, Boris Ostrovsky wrote: >>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >>> index 811e4ddb3f37..a3dcd83187ce 100644 >>> --- a/arch/x86/xen/enlighten_pv.c >>> +++ b/arch/x86/xen/enlighten_pv.c >>> @@ -579,6 +579,71 @@ static void xen_write_ldt_entry(struct desc_struct *dt, int entrynum, >>> preempt_enable(); >>> } >>> >>> +#ifdef CONFIG_X86_64 >>> +static struct { >>> + void (*orig)(void); >>> + void (*xen)(void); >>> + bool ist_okay; >>> + bool handle; >>> +} trap_array[] = { >>> + { debug, xen_xendebug, true, true }, >>> + { int3, xen_xenint3, true, true }, >>> + { double_fault, xen_double_fault, true, false }, >> Is it really worth adding 'handle' member to the structure because of a >> single special case? We don't expect to ever have another such vector. > Hmm, maybe you are right. We don't expect to ever see a double_fault in > a pv domain, so we could just drop that special case by handling it like > the other IST traps. (This is steeped in a lot of history.) There is no path where Xen will raise #DF with a PV guest. As Linux sets the DPL of the #DF handler to 0, the `int $8` emulation will inject #GP (even for kernel uses!) rather than follow the #DF path. I do however want to see about making Xen's behaviour rather more architectural, e.g. raising #NP rather than crashing the guest. If we do get to a position of properly using contributory exceptions, #DF will behave as #MC and #NMI currently do, by either switching from userspace to the kernel stack, or pushed normally onto the current stack. In some copious free time, it might also be good to invent a PV ABI to behave like IST (even if only for the failsafe callback) so Linux can actually recover sufficiently from a stack overflow to print some diagnostics. ~Andrew