Received: by 10.213.65.68 with SMTP id h4csp575658imn; Thu, 22 Mar 2018 04:06:16 -0700 (PDT) X-Google-Smtp-Source: AG47ELuCAxpuHRiAdV06yMp81qk15uatgLcmZL9QIxAXalL6DqBzEZ3+jw7ZlMp0PwGbXCredDs5 X-Received: by 2002:a17:902:42e:: with SMTP id 43-v6mr5940214ple.186.1521716776491; Thu, 22 Mar 2018 04:06:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521716776; cv=none; d=google.com; s=arc-20160816; b=nz/RHwyklagX7icjFmx1if/jsn0aWxo/A8oDC6d1OtgCidKWX0XvQhgBAbE2AzvFFW vAYUUWtymxbRSxUpGWudoxN7E3MfmPpq74QhG1teiy/eVxZZpbpoMI5t70i5Mt6WD87q 2X6opC3JA6dlOMMynJ+3JW8fbDIe1iOFfjP82lUKaZEtHepqFsZiNiNcUu/HfmVvrCV1 q/9igIhbNqaJ+fyZCOJ9BBvZVKoyoRa3LP9ujyZDOGIHBcOD26kFBlT9j+M0A2jBSYMu PxfZcUdlj/s1opxWI7sPXFU4Hyy+gLF22YruFTKKEDGKBF4Y2L/jWY9xPHkGLhqb53HB 74og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=D2JW+CD174Q0RdHjsmVSvY65mvhdxv8yGn/zpfGyCgQ=; b=nAGGb7bu9iFHT97aW6ZK3vA2b9G2ZdWG9owl9RTx+hgNWOY/btOZfozOEPp/nE55rU WZkryi5qPWkPA+Fc+W93F8+9URSSdI2XJUiZ9LUkioiwf2C88BpKAv/h6HAAdKRoN5SV yGzr+ROKRuyaJ7X3WoQRTYgkEnghvxE2zqKNlqbFbG7Iv35AiMTNJ7l/+hjqaTCl6wVf o4vETjyE2oyM8W+EkmT3oB4ZLA1yAqNLCbZp/apPSLaaCJxnSxpBOvylUkCrrWbGgfLH UdQwBPLeu/BQhzSBQonc/2lR9KmYlLO3S7wBVnjeW4k+JCZs8PPS6RE+erL3thXbUZS/ Ho3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n6-v6si5793417plp.574.2018.03.22.04.05.57; Thu, 22 Mar 2018 04:06:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753890AbeCVLFC (ORCPT + 99 others); Thu, 22 Mar 2018 07:05:02 -0400 Received: from ppsw-42.csi.cam.ac.uk ([131.111.8.142]:54544 "EHLO ppsw-42.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752266AbeCVLE7 (ORCPT ); Thu, 22 Mar 2018 07:04:59 -0400 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-111-108-209.dynamic.dsl.as9105.com ([88.111.108.209]:51275 helo=[192.168.1.6]) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1eyy1h-000NIE-8F (Exim 4.89_2) (return-path ); Thu, 22 Mar 2018 11:04:58 +0000 Subject: Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode To: Paolo Bonzini , Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= References: <1521707651-9375-1-git-send-email-wanpengli@tencent.com> <49454fe4-16e2-4d8b-7ad5-9e488afc786e@citrix.com> From: Andrew Cooper Message-ID: Date: Thu, 22 Mar 2018 11:04:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/03/2018 10:42, Paolo Bonzini wrote: > On 22/03/2018 11:19, Andrew Cooper wrote: >> On 22/03/2018 10:07, Paolo Bonzini wrote: >>> On 22/03/2018 09:34, Wanpeng Li wrote: >>>> From: Wanpeng Li >>>> >>>> Explicit segment overides other than %fs and %gs are documented as ignored by >>>> both Intel and AMD. >>>> >>>> In practice, this means that: >>>> >>>> * Explicit uses of %ss don't actually yield #SS[0] for non-canonical >>>> memory references. >>>> * Explicit uses of %{e,c,d}s don't override %rbp/%rsp-based memory references >>>> to yield #GP[0] for non-canonical memory references. >>>> >>>> Cc: Paolo Bonzini >>>> Cc: Radim Krčmář >>>> Signed-off-by: Wanpeng Li >> When porting fixes from other projects, it is customary to identify so >> in the commit message.  In this case, the fix you've ported is >> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=b7dce29d9faf3597d009c853ed1fcbed9f7a7f68 >> >> Here is an example of how Xen ports fixes from Linux for the drivers >> that we share.  >> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=4e131596f1defec9407b6e60d584a696beaf5d7e > Thanks Andrew. The code is of course completely different, but the > commit message is 1:1. Wanpeng, please acknowledge Jan in v2! Thanks, but it is actually my patch, which is why I was confused at seeing my own commit message on LKML. Also, the chances are that there are similar issues decoding the instruction info field in the VMCS, which is how I stumbled onto this in the first place.  I haven't yet fixed that side of things for Xen. > >>> Testcase, please... >> If you want to crib from one, this is the testcase I made for Xen. >> >> http://xenbits.xen.org/docs/xtf/test-memop-seg.html > How does it ensure that the code is executed through the emulator and > not by the processor? This test, and most of the tests in general, deliberately set things up to execute the test cases first on the main processor, and then via the emulator, and complain when any result is unexpected. We've got a Force Emulation Prefix (ud2a; .ascii "xen") for doing magic.  Originally, this was used for PV guests to explicitly request an emulated CPUID, but I extended it to HVM guests for "emulate the next instruction", after we had some guest user => guest kernel privilege escalations because of incorrect emulation. Fundamentally, any multi-vcpu guest can force an arbitrary instruction through the emulator, because rewriting a couple of bytes of instruction stream is far far far faster than a vmexit.  I chose to introduce a explicit way to force this to occur, for testing purposes. > >> With the impending KVM/PVH work which is ongoing, it will soon be easy >> to run Xen's HVM test suite unmodified under KVM, but we're not quite >> there yet. > What does the test suite use for console I/O? Depends on what it available as it boots, but one of the default consoles is port 0x12.  If things need to be tweaked to work more cleanly, then that is entirely fine. ~Andrew