From patchwork Thu Apr 6 16:32:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 9667907 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 392BE601EB for ; Thu, 6 Apr 2017 16:42:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E400F1FE83 for ; Thu, 6 Apr 2017 16:42:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D6B86204BD; Thu, 6 Apr 2017 16:42:20 +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 4CB941FE83 for ; Thu, 6 Apr 2017 16:42:18 +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 1cwARh-0008HU-1o; Thu, 06 Apr 2017 16:39:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwARg-0008HO-32 for xen-devel@lists.xen.org; Thu, 06 Apr 2017 16:39:40 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 7B/A3-13971-B4F66E85; Thu, 06 Apr 2017 16:39:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRWlGSWpSXmKPExsWyU9JRQtc9/1m EwZMZOhZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8btHRYFfxUr/r6ezNjAeEuqi5GTQ0LAT2J2 3x1GEFtYIFni4Kbr7CC2iICyRO+v3yxdjFwcQgJdzBJX/x5gBHGYBSYwSvybcIUZpIpNQF9i9 4tPTCA2r4CtxPJ5z8BsFgEVif2XFrCC2KICwRIHJt5gh6gRlDg58wkLiM0pYC+x9s9esDnMAg YSRxbNYYWw5SW2v50DFhcSUJO41n+JHeLSdIkDcy+xTGDkn4Vk1Cwk7bOQtC9gZF7FqFGcWlS WWqRraKGXVJSZnlGSm5iZo2toYKqXm1pcnJiempOYVKyXnJ+7iREYhgxAsIOxabvnIUZJDiYl UV4FnycRQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4c/KeRQgJFqWmp1akZeYAIwImLcHBoyTCy weS5i0uSMwtzkyHSJ1iVJQS5/UFSQiAJDJK8+DaYFF4iVFWSpiXEegQIZ6C1KLczBJU+VeM4h yMSsK8kiBTeDLzSuCmvwJazAS02OfWU5DFJYkIKakGxi0XH03pyLa6Ltm33uR6zS253FmiM6U nLrWQijz5PkH2vodi8T+TZWzHb9gLTF33SG7NsiOuRjcb1ZY87KyIi2H0Xtr/P1zv67kt/xcd EjEut7x3XvjMv59H3madWvdv0ct97NuPTK+3jbN5zVvMyhTVsVl5jtzmsMq/Oy9ec4nZmSV75 echvUtKLMUZiYZazEXFiQBFqfAwvQIAAA== X-Env-Sender: prvs=262ab663b=Andrew.Cooper3@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1491496775!76769621!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.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2400 invoked from network); 6 Apr 2017 16:39:35 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Apr 2017 16:39:35 -0000 X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208";a="43871343" 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> <15376186-772a-75a3-eb2e-cc268ccdd4a4@citrix.com> <58E6696C020000780014E062@prv-mh.provo.novell.com> From: Andrew Cooper Message-ID: Date: Thu, 6 Apr 2017 17:32:01 +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: <58E6696C020000780014E062@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 15:14, Jan Beulich wrote: >>>> On 06.04.17 at 11:47, wrote: >> 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. > Right. > >> 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. > That's not the conclusion I would draw. There is a reason we emulate > call gate accesses already now for 32-bit guests (just not via > x86_emulate()) - precisely to guarantee guests need _not_ be aware. > >> 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. > I don't think the validate function should do any such overriding. > Specifically it shouldn't alter ctxt->lma, risking to surprise x86_emulate(). I have folded: unsigned int eflags, ar; Reviewed-by: Jan Beulich diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index d010aa3..96bc280 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5412,7 +5412,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long addr, .vendor = d->arch.cpuid->x86_vendor, .addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG, .sp_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG, - .lma = true, + .lma = !is_pv_32bit_domain(d), }, }; int rc; @@ -5567,7 +5567,7 @@ int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr, .vendor = v->domain->arch.cpuid->x86_vendor, .addr_size = addr_size, .sp_size = addr_size, - .lma = true, + .lma = !is_pv_32bit_vcpu(v), .data = &mmio_ro_ctxt }; int rc; diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 09dc2f1..5b9bf21 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2966,7 +2966,7 @@ static int emulate_privileged_op(struct cpu_user_regs *regs) struct priv_op_ctxt ctxt = { .ctxt.regs = regs, .ctxt.vendor = currd->arch.cpuid->x86_vendor, - .ctxt.lma = true, + .ctxt.lma = !is_pv_32bit_domain(currd), }; int rc;