From patchwork Thu Apr 6 09:47:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 9666767 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6E56660364 for ; Thu, 6 Apr 2017 09:50:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 58AAF27317 for ; Thu, 6 Apr 2017 09:50:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 488FD28249; Thu, 6 Apr 2017 09:50:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D6B5F27317 for ; Thu, 6 Apr 2017 09:50:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cw418-0003Jm-TY; Thu, 06 Apr 2017 09:47:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cw417-0003Jg-Vh for xen-devel@lists.xen.org; Thu, 06 Apr 2017 09:47:50 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 76/4C-00609-5CE06E85; Thu, 06 Apr 2017 09:47:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRWlGSWpSXmKPExsWyU9JRQvcI37M Ig0ffFC2WfFzM4sDocXT3b6YAxijWzLyk/IoE1ozbf1azFpxUqJj77C1bA2O3VBcjJ4eEgJ/E pHW7mEFsYYFkiYObrrOD2CICyhK9v36zdDFycQgJLGaS6P7cyA7iMAtMYJT4N+EKWAebgL7E7 hefmEBsXgFbieNr14DZLAIqEqtvHWAFsUUFgiUOTLzBDlEjKHFy5hMWEJtTwF7i66ulYPXMAg YSRxbNYYWw5SW2v50DNl9IQE3iWv8ldohL0yUOzL3EMoGRfxaSUbOQtM9C0r6AkXkVo0ZxalF ZapGuoYVeUlFmekZJbmJmjq6hgbFebmpxcWJ6ak5iUrFecn7uJkZgINYzMDDuYPx92vMQoyQH k5Ior4LPkwghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKErzLeJ9FCAkWpaanVqRl5gBjAiYtwcGjJ ML7DiTNW1yQmFucmQ6ROsWoKCXOKwKMJCEBkERGaR5cGywOLzHKSgnzMjIwMAjxFKQW5WaWoM q/YhTnYFQS5g0EGc+TmVcCN/0V0GImoMU+t56CLC5JREhJNTAaxu/eXNa7/bL+/4W311jL/fG cd1mVNeBEbOilnx5rn0qpiEaWGs10ZP8avb50neBGx3/vHn/6vewCm0sUw43jpVGyqXlsOkn/ 9oilrPhcX7/Zqf77/GWFlVLrYvmDC/9mNK5PtFWx3uN1k3Gt7q7TqSxecxJUZS99fMBQ91L5f 4D5I7/LW9OUWIozEg21mIuKEwH6iv2XvgIAAA== X-Env-Sender: prvs=262ab663b=Andrew.Cooper3@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1491472068!36441530!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15924 invoked from network); 6 Apr 2017 09:47:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 6 Apr 2017 09:47:48 -0000 X-IronPort-AV: E=Sophos;i="5.37,159,1488844800"; d="scan'208";a="43837202" To: Jan Beulich References: <1490989853-21879-1-git-send-email-andrew.cooper3@citrix.com> <1490989853-21879-7-git-send-email-andrew.cooper3@citrix.com> <58E23BB2020000780014C029@prv-mh.provo.novell.com> <9a7b9777-c4d9-cad3-224a-3ff590393a20@citrix.com> <58E6033B020000780014DAAE@prv-mh.provo.novell.com> From: Andrew Cooper Message-ID: <15376186-772a-75a3-eb2e-cc268ccdd4a4@citrix.com> Date: Thu, 6 Apr 2017 10:47:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <58E6033B020000780014DAAE@prv-mh.provo.novell.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL01.citrite.net (10.69.22.125) Cc: Julien Grall , Paul Durrant , Tim Deegan , Xen-devel Subject: Re: [Xen-devel] [PATCH for 4.9 6/6] x86/emul: Require callers to provide LMA in the emulation context X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 06/04/17 07:58, Jan Beulich wrote: >>>> On 05.04.17 at 18:24, wrote: >> On 03/04/17 11:10, Jan Beulich wrote: >>>>>> On 31.03.17 at 21:50, wrote: >>>> --- a/xen/arch/x86/mm.c >>>> +++ b/xen/arch/x86/mm.c >>>> @@ -5410,6 +5410,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long addr, >>>> .ctxt = { >>>> .regs = regs, >>>> .vendor = d->arch.cpuid->x86_vendor, >>>> + .lma = true, >>>> .addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG, >>>> .sp_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG, >>>> }, >>>> @@ -5564,6 +5565,7 @@ int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr, >>>> struct x86_emulate_ctxt ctxt = { >>>> .regs = regs, >>>> .vendor = v->domain->arch.cpuid->x86_vendor, >>>> + .lma = true, >>> Hmm, both of these are correct from Xen's pov, but potentially >>> wrong from the guest's. Since system segments aren't being >>> dealt with here, I think this difference is benign, but I think it >>> warrants at least a comment. If we ever meant to emulate >>> LLDT, this would become at active problem, as the guest's view >>> on gate descriptor layout would differ from that resulting from >>> setting .lma to true here. Same for emulate_privileged_op() then. >> As discovered in the meantime, things like LLDT/LTR and call gates are >> far more complicated. >> >> Still, setting LMA to true here is the right thing to do, as it is an >> accurate statement of processor state. Despite the level of >> compatibility for 32bit, a 32bit PV guest isn't entirely isolated from >> the fact that Xen is 64bit. > Yes, but still call gates (which we don't currently handle in the > emulator itself) require 32-bit treatment for 32-bit guests, so > setting lma to true would still seem wrong. I thought you said that a compatibility mode `call $gate` still checked the type in the high 8 bytes. A 32bit PV guest therefore needs to be aware that it can't position call gates adjacently, or it will suffer #GP[sel] for a failed typecheck. Now, in this specific case we are in a position to cope, because either way we end up in the gate op code, but if we wanted to override hardware behaviour, it should be the validate function, which positively identifies a far call/jmp, which should choose to override lma for the purposes of faking up legacy mode behaviour. > And the value of lma > is, as we now know, irrelevant for LDT and TSS descriptors (I'm > about to verify AMD behaves identically to Intel here). I checked AMD when I was testing this quirk. The behaviour does appear to be the same. > >>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h >>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h >>>> @@ -457,6 +457,9 @@ struct x86_emulate_ctxt >>>> /* Set this if writes may have side effects. */ >>>> bool force_writeback; >>>> >>>> + /* Long mode active? */ >>>> + bool lma; >>> I don't think this should be in the input only section, as an insn >>> can have the effect of clearing it. >>> >>> Also should x86_emulate_wrapper() perhaps assert the field to >>> be false for 32-bit (test harness) builds? >> I'd prefer not to. There is nothing in principle wrong with trying to >> feed a 32bit compatibility segment through a 32bit build of the test >> harness. > Actually I've just figured myself that such an assertion would better > be checking that mode_64bit() implies lma to be set. Good point. I have folded: if ( rc != X86EMUL_OKAY ) ~Andrew diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index 1d5a698..59c2da8 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -7895,7 +7895,12 @@ int x86_emulate_wrapper( const struct x86_emulate_ops *ops) { unsigned long orig_ip = ctxt->regs->r(ip); - int rc = x86_emulate(ctxt, ops); + int rc; + + if ( mode_64bit() ) + ASSERT(ctxt->lma); + + rc = x86_emulate(ctxt, ops); /* Retire flags should only be set for successful instruction emulation. */