From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.14045.1590157884754741846 for ; Fri, 22 May 2020 07:31:25 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Jfe13esA; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590157883; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TjV6t5mMBR9cP4bIzsdzZ9/To+WwYhjEH+1KqR5YS54=; b=Jfe13esAdRdEtFByk0982fC6KVeYJSglLJFOhJu9frCyCcWkL4o35kG87K52+H5EJshqZ1 uWar5YCt6IWfO2sonFIylmkKNxo2qUK83dlgRjHylK2K/c2IrefQe+SzqtG2PNwCQBMUmc r2/HrGxVgp4E4NaZ5cFBXoR8v14Y1GM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-34-ZtaG0wd1MwyGstvqPEUnwQ-1; Fri, 22 May 2020 10:31:19 -0400 X-MC-Unique: ZtaG0wd1MwyGstvqPEUnwQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3B78D18FE86E; Fri, 22 May 2020 14:31:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-40.ams2.redhat.com [10.36.112.40]) by smtp.corp.redhat.com (Postfix) with ESMTP id C9BB91CA; Fri, 22 May 2020 14:31:15 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v8 17/46] OvmfPkg/VmgExitLib: Add support for NPF NAE events (MMIO) From: "Laszlo Ersek" To: devel@edk2.groups.io, thomas.lendacky@amd.com Cc: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , Brijesh Singh , Ard Biesheuvel References: <1a5f159a487e2f20b5ad7bff83659fb1442ecbcd.1589925074.git.thomas.lendacky@amd.com> <169e44cb-2c1c-6d9a-342a-2a1f618e3753@redhat.com> Message-ID: <139ce789-b938-c8b9-030e-c1b6c67e47ea@redhat.com> Date: Fri, 22 May 2020 16:31:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <169e44cb-2c1c-6d9a-342a-2a1f618e3753@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 05/22/20 16:14, Laszlo Ersek wrote: > INT64 Displacement; > Displacement *= (1 << Ext->Sib.Scale); > (10c) Multiplying a negative INT64 by 1, 2, 4, or 8 is well-defined > (assuming again that the initial Displacement value is small enough, > which depends on the original instruction). > > If we wanted to be super-safe, we could replace this open-coded > INT64 multiplication with a call to SafeInt64Mult(), from > , and hang here, if the call fails. > > Up to you. Side comment: normally, even if we were 100% sure the result would be in range, we shouldn't use the "*" operator for INT64 multiplication -- because of intrinsics. BaseLib offers MultS64x64() for that problem. But, this is X64-only code. So using "*" for INT64 multiplication should be fine on all toolchains, regarded purely from an intrinsics perspective. So it's a choice between "*" (if we trust the instruction being decoded to be sane) or SafeInt64Mult() (if we don't). MultS64x64() sits in the middle, and doesn't buy us anything here. Thanks Laszlo