From patchwork Mon Jan 25 10:16:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Roger_Pau_Monn=C3=A9?= X-Patchwork-Id: 8106381 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 3B1F59F440 for ; Mon, 25 Jan 2016 10:20:01 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3BBE8202EC for ; Mon, 25 Jan 2016 10:20:00 +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 2962A20270 for ; Mon, 25 Jan 2016 10:19:59 +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 1aNeCl-0007LL-Lj; Mon, 25 Jan 2016 10:17:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aNeCk-0007LG-Bg for xen-devel@lists.xenproject.org; Mon, 25 Jan 2016 10:17:02 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 70/DC-13905-D16F5A65; Mon, 25 Jan 2016 10:17:01 +0000 X-Env-Sender: royger@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1453717020!17616596!1 X-Originating-IP: [74.125.82.68] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 45070 invoked from network); 25 Jan 2016 10:17:01 -0000 Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by server-16.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 25 Jan 2016 10:17:01 -0000 Received: by mail-wm0-f68.google.com with SMTP id u188so10349222wmu.0 for ; Mon, 25 Jan 2016 02:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=+zVp6wXuutlG+fvA9ml26TAZdimH9W7AHr+L4+zngK4=; b=vsbe9XqG4tSV9Srf+Ylp37Q7RDFjEthUb9s/zkjnrafi2F68BPRJu4D301i8SXV5UH 6YmRFGgwcSfT9r56FLNB1er/+T627zCmfXsb5/727oGDeWTvj2E140NHbc15fQDAHiJU jmLKgAWENv2hDrDqF4/95sNuBfPw+zUTGxn56CyGdRkBknx9IWZSLFBip1gUNK3EcFAO 6S9E8XaCETOYV38CEq7gFn49n+i27ylC9GY7ZIMMz04MVCPK39B63UB0IXYzH4rqZVHM zNqxbWd0jCm4WOjnGTdxK70fVTO/+X3ceNTbdJ60hTKSttnVVxrbK21eEvgl1DvfLWeG qPyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-type:content-transfer-encoding; bh=+zVp6wXuutlG+fvA9ml26TAZdimH9W7AHr+L4+zngK4=; b=WmsDS9sc/tqP9NuU/YXtqZCTLOUlPrOfPt5tvp4R+bXrPfVYTtRJYfkewkvqEXWsBi 41jiAdytDopgiBcOi4wswYtNgCQizn/3APGicq8wcZdnY3ZR3uAr9Ck3Rn4bhc5/QeG+ oopkZBwC/Auyg4sQKXc8RonkTm9yJPKCbJyJicTUdjKGDxFeKRGtjksHv3hhxcAEuu6P 97Llth22L9o/e7gUPHfR585EBIn0qtVGOWuSgT3tsGZ1VoalyrfHBPpf7ZlfN/w7VGN9 mY2erHzqTcfEeVVliiv8Xz4YQQ1oox8V63ZqoD7450P0OR4BW00bmXV7b2522dj1gLVD CqPg== X-Gm-Message-State: AG10YOQaKDMoSnV+8LebdWcSoWTN81gSV7OFpitxs+2zbaMAGSs/30O7CAfagrAfeUf5Sg== X-Received: by 10.28.232.208 with SMTP id f77mr18049741wmi.34.1453717020589; Mon, 25 Jan 2016 02:17:00 -0800 (PST) Received: from localhost.localdomain (50.Red-88-7-9.staticIP.rima-tde.net. [88.7.9.50]) by smtp.gmail.com with ESMTPSA id lc1sm15963937wjc.5.2016.01.25.02.16.58 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 25 Jan 2016 02:16:59 -0800 (PST) From: Roger Pau Monne To: xen-devel@lists.xenproject.org Date: Mon, 25 Jan 2016 11:16:49 +0100 Message-Id: <1453717009-91577-1-git-send-email-royger@FreeBSD.org> X-Mailer: git-send-email 1.9.5 (Apple Git-50.3) MIME-Version: 1.0 Cc: Ian Campbell , Andrew Cooper , Tim Deegan , Jan Beulich , Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v2] x86/HVMlite: document the BSP/AP boot ABI 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 From: Roger Pau Monne The discussion in [1] lead to an agreement of the missing pieces in PVH (or HVM without a device-model) in order to progress with it's implementation. One of the missing pieces is a new boot ABI, that replaces the PV boot ABI. The aim of this new boot ABI is to remove the limitations of the PV boot ABI, that are no longer present when using auto-translated guests. The new boot protocol should allow to use the same entry point for both 32bit and 64bit guests, and let the guest choose it's bitness at run time without the domain builder knowing in advance. This patch introduces a new document called hvmlite.markdown, with the intention of merging it into pvh.markdown once the HVMlite implementation has feature parity with PVH and the old PVH ABI is replaced with the HVMlite one. [1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html Signed-off-by: Roger Pau Monné --- Cc: Ian Campbell Cc: Ian Jackson Cc: Jan Beulich Cc: Tim Deegan Cc: Andrew Cooper --- Changes since v1: - Prepend x86 to the title. - Consistently use "must". --- docs/misc/hvmlite.markdown | 82 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 docs/misc/hvmlite.markdown diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown new file mode 100644 index 0000000..c1b75c6 --- /dev/null +++ b/docs/misc/hvmlite.markdown @@ -0,0 +1,82 @@ +**NOTE**: this document will be merged into `pvh.markdown` once PVH is replaced +with the HVMlite implementation. + +# x86/HVM direct boot ABI # + +Since the Xen entry point into the kernel can be different from the +native entry point, a `ELFNOTE` is used in order to tell the domain +builder how to load and jump into the kernel entry point: + + ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long, xen_start32) + +The presence of the `XEN_ELFNOTE_PHYS32_ENTRY` note indicates that the +kernel supports the boot ABI described in this document. + +The domain builder must load the kernel into the guest memory space and +jump into the entry point defined at `XEN_ELFNOTE_PHYS32_ENTRY` with the +following machine state: + + * `ebx`: contains the physical memory address where the loader has placed + the boot start info structure. + + * `cr0`: bit 0 (PE) must be set. All the other writeable bits are cleared. + + * `cr4`: all bits are cleared. + + * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’ + and a limit of ‘0xFFFFFFFF’. The selector value is unspecified. + + * `ds`, `es`: must be a 32-bit read/write data segment with a base of + ‘0’ and a limit of ‘0xFFFFFFFF’. The selector values are all unspecified. + + * `tr`: must be a 32-bit TSS (active) with a base of '0' and a limit of '0x67'. + + * `eflags`: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. + Bit 8 (TF) must be cleared. Other bits are all unspecified. + +All other processor registers and flag bits are unspecified. The OS is in +charge of setting up it's own stack, GDT and IDT. + +The format of the boot start info structure is the following (pointed to +be %ebx): + + struct hvm_start_info { + #define HVM_START_MAGIC_VALUE 0x336ec578 + uint32_t magic; /* Contains the magic value 0x336ec578 */ + /* ("xEn3" with the 0x80 bit of the "E" set).*/ + uint32_t flags; /* SIF_xxx flags. */ + uint32_t cmdline_paddr; /* Physical address of the command line. */ + uint32_t nr_modules; /* Number of modules passed to the kernel. */ + uint32_t modlist_paddr; /* Physical address of an array of */ + /* hvm_modlist_entry. */ + }; + + struct hvm_modlist_entry { + uint32_t paddr; /* Physical address of the module. */ + uint32_t size; /* Size of the module in bytes. */ + }; + +Other relevant information needed in order to boot a guest kernel +(console page address, xenstore event channel...) can be obtained +using HVMPARAMS, just like it's done on HVM guests. + +The setup of the hypercall page is also performed in the same way +as HVM guests, using the hypervisor cpuid leaves and msr ranges. + +## AP startup ## + +AP startup is performed using hypercalls. The following VCPU operations +are used in order to bring up secondary vCPUs: + + * `VCPUOP_initialise` is used to set the initial state of the vCPU. The + argument passed to the hypercall must be of the type vcpu_hvm_context. + See `public/hvm/hvm_vcpu.h` for the layout of the structure. Note that + this hypercall allows starting the vCPU in several modes (16/32/64bits), + regardless of the mode the BSP is currently running on. + + * `VCPUOP_up` is used to launch the vCPU once the initial state has been + set using `VCPUOP_initialise`. + + * `VCPUOP_down` is used to bring down a vCPU. + + * `VCPUOP_is_up` is used to scan the number of available vCPUs.