Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3520723ybz; Mon, 27 Apr 2020 17:37:25 -0700 (PDT) X-Google-Smtp-Source: APiQypK0zKZEgPNPVUjvoly9J59oXhG7NoMyaylGRx2BCnCFjMPXbNhjKBhiplpmtt0THgYRliXu X-Received: by 2002:aa7:cf0e:: with SMTP id a14mr7699698edy.188.1588034245073; Mon, 27 Apr 2020 17:37:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588034245; cv=none; d=google.com; s=arc-20160816; b=saSe47FcJbkA2QbUTLMNWycdEsk74IINNsJcFUvAJzh1AAXE469dTsNowVvLAGvacW itlGWvxt3GDbuTb1WFtZF55Wcik/q259TOgG39SdI+cvIKgNsYRr4Ws5hLlrO+RJWr0M Y0TnptIWQ1bqRPohfDGbYNWyfVBDfF1e3JL7BHW96fcuGeeVYoLi/Gfvkv+Zsb/n0qgW /hUZ0o2vvsPabIoZkhvUhz7gKcbKTCmFiL6hWOw0kV2UA56GcZrTuJGBrn7LQ6sDIL2a G/ThlQ7d5LWta5enZnMSigmVY7juRPxKLFXGt8FmMu1a4BXFGdSusyXOSf7hkP8OHfP3 vI3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=+xuDgjWGTY2Rhs96pjCnJ9ds7BI4aNMEObhL4I29plQ=; b=NLfSwS+Z8mckqr50RENpFydFbednmZyfYXIVRecq+jX/aMGtkGN0PXwKhHM+BEw2rr U5CcM+OfWe+BgJcN1j2xe8GveZ3N/tRJX6f+clfRX+DHShPRIGpA4zxWL1wpw3WqZdIr u1jDS4ujjM+ELdVOXKG7n9nbGYBBTNVL6XXsT7Zbh77ZHcnCmFpelxtFq/QF0TMELpTp xJAGTD44XD+IlS4k3PWYh8nywfu5lT8ldI1XZwhHrV/D5T9cSeYw8TlbzPHJxfxci7dJ vc9ScwAdbvV72vGgNy1qQlFEjsQK50/QTHlccIUqJ1rNPeEoCF/pgXn+FkWDWzbnkhiN S+2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z13si778472eju.18.2020.04.27.17.37.02; Mon, 27 Apr 2020 17:37:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726469AbgD1AdS (ORCPT + 99 others); Mon, 27 Apr 2020 20:33:18 -0400 Received: from mga05.intel.com ([192.55.52.43]:41331 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726257AbgD1AdS (ORCPT ); Mon, 27 Apr 2020 20:33:18 -0400 IronPort-SDR: bJPqrIgYsP/8gUvWXDNFgWasencwxvuOXDd/dXczGGfEe/70e140c0EKNoKbW7+vfTlkuWFYUn X2LsuURMGjng== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2020 17:33:17 -0700 IronPort-SDR: 9KpS+xelx3QsJwLoqXzGT5Rmn2Xu98is1rERQcf+WvISeXIKF/KRSRAqW3NMmMp3m8S0sWUpry 4ZbvqplHqZhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,325,1583222400"; d="scan'208";a="246333189" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga007.jf.intel.com with ESMTP; 27 Apr 2020 17:33:17 -0700 Date: Mon, 27 Apr 2020 17:33:17 -0700 From: Sean Christopherson To: Jim Mattson Cc: Paolo Bonzini , LKML , kvm list , Joerg Roedel , everdox@gmail.com Subject: Re: [PATCH] KVM: x86: handle wrap around 32-bit address space Message-ID: <20200428003317.GC14870@linux.intel.com> References: <20200427165917.31799-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 27, 2020 at 05:28:54PM -0700, Jim Mattson wrote: > On Mon, Apr 27, 2020 at 9:59 AM Paolo Bonzini wrote: > > @@ -1568,8 +1568,17 @@ static int skip_emulated_instruction(struct kvm_vcpu *vcpu) > > */ > > if (!static_cpu_has(X86_FEATURE_HYPERVISOR) || > > to_vmx(vcpu)->exit_reason != EXIT_REASON_EPT_MISCONFIG) { > > - rip = kvm_rip_read(vcpu); > > - rip += vmcs_read32(VM_EXIT_INSTRUCTION_LEN); > > + orig_rip = kvm_rip_read(vcpu); > > + rip = orig_rip + vmcs_read32(VM_EXIT_INSTRUCTION_LEN); > > +#ifdef CONFIG_X86_64 > > + /* > > + * We need to mask out the high 32 bits of RIP if not in 64-bit > > + * mode, but just finding out that we are in 64-bit mode is > > + * quite expensive. Only do it if there was a carry. > > + */ > > + if (unlikely(((rip ^ orig_rip) >> 31) == 3) && !is_64_bit_mode(vcpu)) > > Is it actually possible to wrap around 0 without getting a segment > limit violation, or is it only possible to wrap *to* 0 (i.e. rip==1ull > << 32)? Arbitrary wrap is possible. Limit checks are disabled for flat segs, it's a legacy bug^W feature.