Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752143AbbKPUcO (ORCPT ); Mon, 16 Nov 2015 15:32:14 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:24576 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751855AbbKPUcM (ORCPT ); Mon, 16 Nov 2015 15:32:12 -0500 Subject: Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit To: Andy Lutomirski References: <1447456706-24347-1-git-send-email-boris.ostrovsky@oracle.com> <56468D24.8030801@oracle.com> <564A0371.2040104@oracle.com> Cc: "linux-kernel@vger.kernel.org" , xen-devel , David Vrabel , Konrad Rzeszutek Wilk , Borislav Petkov From: Boris Ostrovsky Message-ID: <564A3D38.4030607@oracle.com> Date: Mon, 16 Nov 2015 15:31:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1596 Lines: 44 On 11/16/2015 02:03 PM, Andy Lutomirski wrote: > It's still a waste of effort, though. Also, I'd eventually like the > number of places in Xen code in which rsp/esp is invalid to be exactly > zero, and this approach makes this harder or even impossible. That's what PVH is going to do. > Does PVH hook into the entry asm code at all? I thought it was just > boot code and drivers. Not the current version --- it starts with xen_start_kernel(). But we are currently changing it and my plan is to have a small stub executed initially (to set bootparams and such) and then jump to startup_{32|64}(). > > In any case, someone needs to do some serious review and cleanup on > the whole paravirt op mess. We have a bunch of paravirt ops that > serve little purpose. > > The paravirt infrastructure is a bit weird, too: it seems to > effectively have four states for each patch site. There's: > > 1. The initial state, which is unoptimized and works on native. > Presumably any of these that happen early also need to work, if > slowly, on Xen. Not on PV (and as of today, on PVH) --- we start directly from xen_start_kernel(). I.e. from step 2. > > 2. The Xen state without text patching. I'm not actually sure why > this exists at all. Are there pvops that need to switch too early for > us to patch the text? I don't think so. -boris -- 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/