From patchwork Fri Jan 15 22:08:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 8044761 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 064B8BEEED for ; Fri, 15 Jan 2016 22:12:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0761F2037F for ; Fri, 15 Jan 2016 22:12:16 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EC8EE20357 for ; Fri, 15 Jan 2016 22:12:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aKCYb-0004tZ-Aa; Fri, 15 Jan 2016 22:09:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aKCYW-0004tG-0m for xen-devel@lists.xensource.com; Fri, 15 Jan 2016 22:09:17 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id 6B/8A-17090-B0E69965; Fri, 15 Jan 2016 22:09:15 +0000 X-Env-Sender: mcgrof@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1452895753!15898319!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 46151 invoked from network); 15 Jan 2016 22:09:14 -0000 Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by server-6.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 15 Jan 2016 22:09:14 -0000 Received: by mail-yk0-f173.google.com with SMTP id a85so480789903ykb.1 for ; Fri, 15 Jan 2016 14:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=4MMyzDf9vwzeqCLEdMqKI/sBV3JFuENT3joNcjPjkbs=; b=RK64cczT0XF5HNsVyDG75ElYMT/7oWLR+AqQ+F8IQuwqKeOEIVJCl/7n+tZxUk4c/R kCoX2bYaivHx/8FzKSDqD06sgNpchsWguOEnybAT5f8koWZ5A3ji9/34rsQnZlhKnzLl lE01R7Mc2iQmgSQPS/yhsEMgpEd3ycU/NDKmQPLt+wtCDBS2RhRK9K/0zEH74LfkAAl8 gxUHe9RBh1mD70pw42bHFtB64D8vDo6ILwVbKPsBw0i9WqOau89kqVEs7CQzKcGlUpbr JdWQtXYUlxdC6ipFAIv7dP8/ABIPVtJkz9ITxI+JVK6YzkbMvddbYbz20Tk8aB/nLpOL fkoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-type; bh=4MMyzDf9vwzeqCLEdMqKI/sBV3JFuENT3joNcjPjkbs=; b=mDLcIOHNJUX993k2v525P5DNshFQARKHAMTER/QXV0I+j+ErwW7e7CulvqashUHWQ/ fdOcI1ij7fAyLrU1KE9aaxGtq2opxPQlXcobWvAsU20oacvyuKG5Ys3ywT+LBGrGWVtw N2/YC4WUJ26dVT9xiCH7kwuT8BScSEAwbwxv/r05HcrLFJkjgEVbCjXMzvHzchmjoaoK qkaGIDPRustlq/qGeh1Jy6AoLAMOgbmIbN63oWsk5Y5nxu098r8cYGnLk8QhIieLUGrH sR3FCx5oF5Ed0TQeWPIUGUgZiirP4MWA80xcQtUPMrtUGp+ZfQlNFzixdSb4SMPEKbdl et0A== X-Gm-Message-State: ALoCoQl3JL/FtbfRK7PJk8f1U9Hn81wyybta5t7a4U514wzGkVaYC3RqyLNdA0ZyS7LPfTuSdzI8zVh1AIvDDV37zMxdNSZSGg== X-Received: by 10.129.37.3 with SMTP id l3mr9026090ywl.128.1452895753147; Fri, 15 Jan 2016 14:09:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.215.10 with HTTP; Fri, 15 Jan 2016 14:08:53 -0800 (PST) From: "Luis R. Rodriguez" Date: Fri, 15 Jan 2016 14:08:53 -0800 X-Google-Sender-Auth: pdvjPC3dXoJSYXYf9SK6iB5odCM Message-ID: To: "xen-devel@lists.xensource.com" Cc: Juergen Gross , Jeremy Fitzhardinge , X86 ML , Rusty Russell , "linux-kernel@vger.kernel.org" , Andy Lutomirski , "H. Peter Anvin" , "Luis R. Rodriguez" , Borislav Petkov Subject: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I will be respinning the generic Linux linker table solution [0] soon based on hpa's feedback again now that I'm back from vacation. As I do that though I wanted to highlight a feature I'm throwing into the linker table solution which I am not sure many have paid close attention to but I think is important to Xen. I'm making use of the zero page hardware_subarch to enable us to detect if we're a specific hypervisor solution *as early as is possible*. This has a few implications, short term it is designed to provides a proactive technical solution to bugs such as the cr4 shadow crash (see 5054daa285beaf706f051fbd395dc36c9f0f907f) and ensure that *new* x86 features get a proper Xen implementation proactively *or* at the very least get annotated as unsupported properly, instead of having them crash and later finding out. A valid example here is Kasan, which to this day lacks proper Xen support. In the future, if the generic linker table solution gets merged, it would mean developers would have to *think* about if they support Xen or not at development time. It does this in a not-disruptive way to Xen / x86_64 but most *importantly* it does not extend pvops! This should avoid issues in cases of developer / maintainer bandwidth, should some new features be pushed onto Linux for x86_64 but a respective Xen solution is not addressed, and that was not caught early in patch review, such as with Kasan. [0] https://lkml.kernel.org/r/1450217797-19295-1-git-send-email-mcgrof@do-not-panic.com Two things I'd like to request a bit of help with and review / consideration: 1) I'd like some advice on a curious problem I've stumbled on. I'd like to access hardware_subarch super early, and in my review with at least two x86 folks this *should* work: /* Kill off the identity-map trampoline */ In practice today though this crashes the kernel. One does not need to try to run Xen to test this, simply applying this change should crash a bare metal / qemu instance. If you'd like to force a different value for the subarch you could use this *debug patch* and just use kvm which would set the subarch to a value not yet assigned on Linux: http://drvbp1.linux-foundation.org/~mcgrof/patches/2016/01/15/qemu-add-subarch.patch Simply getting away from he crash is my goal for now. The earliest I can read the subarch as it stands is right after load_idt() on the x86 init path and I simply have no clue why! I'm told this in theory should work. But clearly it does not. I tried running qemu with gdb and I can't get anything sensible out of this so -- I need a bit more x86 help. Why do I want this? It would mean we can cover a proactive solution all the way up to the earliest calls on Linux. Without this the subarch becomes useful only after load_idt(). Since I'm using the subarch to build dependency maps early on it also means that the linker table solution becomes only useful on x86_64_start_reservations() and not x86_64_start_kernel() which is the first C Linux entry point for 64-bit. Having the subarch readible as early as x86_64_start_kernel() means the linker table solution can be used to proactively prevent issues even with discrepancies between x86_64_start_kernel() and x86_64_start_reservations() and xen_start_kernel(). There's another important reason listed below... 2) Provided we address 1) above it could mean it being possible to unify *at least* the C Xen x86_64 init path and the bare metal x86_64 init paths without much code shuffling. Based on discussions at the last Xen developer summit it seemed this was being considered and perhaps desirable. Now the patch below would need a bit more work, but ultimately this gives a small glance at what this could in theory possibly look like: http://drvbp1.linux-foundation.org/~mcgrof/patches/2015/12/15/x86-merge-x86-init-v1.patch The xen init stuff just becomes a Xen specific subarch call. Folks interested in this prospect are welcomed to help review or expand on this work. If you are working on another type of unifying init solution I'd like to hear it as well. Luis diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index c913b7eb5056..9168842821c8 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -141,6 +141,7 @@ static void __init copy_bootdata(char *real_mode_data) asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data) { + struct boot_params *params = (struct boot_params *)__va(real_mode_data); int i; /* @@ -157,6 +158,8 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data) (__START_KERNEL & PGDIR_MASK))); BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END); + boot_params.hdr.hardware_subarch = params->hdr.hardware_subarch; + cr4_init_shadow();