Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4175039imm; Mon, 15 Oct 2018 10:14:42 -0700 (PDT) X-Google-Smtp-Source: ACcGV61/2erkNTe4cCwBHi2krGYk0hpg3jsUAZVYXmjdZ2Wu0LgS7s+T3Mmboq82iItBQ73zB+lx X-Received: by 2002:a62:1407:: with SMTP id 7-v6mr18069844pfu.28.1539623682645; Mon, 15 Oct 2018 10:14:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539623682; cv=none; d=google.com; s=arc-20160816; b=JYulZ/uwB9ftkvX/lZHTnpiN33XBk0gL+FgGkOTyVarg/BCp4cKKgDuKY+fY1oud44 VfLID2/IHOuW8bm4XspAAsX0T3l9KD3eNzVLnSdoi22Qnwg/4yne1nC0W1BGrgmX5smg WW6clJovSRp5MRgr0sUa4aCZC/O/nP+6m0tHQLZz3r9pD1o69bu9NaZOWA533Eg6vJWD bX1gB0XJjmvgQzC9K6Knc+Z//0dOEXmDq1zRHnRquxE79sdIGh9ScyfYMNZNn2G6/DnX vPbYOhgKdaqmXtWM8n+2QWu7UxsIrSKn2sF2mmjgfIyGSq23GnolPW/AhAhi9sNw91im 1tEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject; bh=yd+NKf2BWkyKUXL/2fkbvAOSmG1AgYTSEEjp77b57Rs=; b=duJxlxmbwRlyZN5OYSjytghuuiuT7q63IgkD9CUuS452IMRDZO+X4/F6p+P46YClAK H7GPFXeJsOWKdKIrSkd/QhtUYdWEsveuxh8KFuQ6lkTClTpZXVMDZLINQYC+Sn4UNxRq W5pl+/navAamnUbWx49QGI1xS1jmrdEyf8iKwn6r3gEoT710U1gtwRVbwyESLPOGGiIP +EHS8GMoPyMW2PZ2mmxE2IcVdCGiOjWy3U6T92nGtExDkHLoQ1nPH1RUspR/D8YM6Yhf 2rNNr/2cBNIQM5245ez1UB+/NA3dWEkj9h65PvkJxHr1QZT4k5NCiuUNC6u59AbaEPqA 1zDQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u9-v6si10676719pgh.580.2018.10.15.10.14.27; Mon, 15 Oct 2018 10:14:42 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726932AbeJPA6q (ORCPT + 99 others); Mon, 15 Oct 2018 20:58:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44212 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726831AbeJPA6p (ORCPT ); Mon, 15 Oct 2018 20:58:45 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 51117308FB99; Mon, 15 Oct 2018 17:12:39 +0000 (UTC) Received: from [10.36.117.209] (ovpn-117-209.ams2.redhat.com [10.36.117.209]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2D0B662474; Mon, 15 Oct 2018 17:12:35 +0000 (UTC) Subject: Re: [PATCH] kvm/x86 : avoid shifting signed 32-bit value by 31 bits To: Wei Yang , peng.hao2@zte.com.cn Cc: penghao122@sina.com.cn, rkrcmar@redhat.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, joro@8bytes.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org References: <20181006070849.psgrrhiysnrytbjr@master> <201810080904344038939@zte.com.cn> <20181008022532.4ve2xww4yphk6f5d@master> From: Paolo Bonzini Openpgp: preference=signencrypt Autocrypt: addr=pbonzini@redhat.com; prefer-encrypt=mutual; keydata= xsEhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAc0f UGFvbG8gQm9uemluaSA8Ym9uemluaUBnbnUub3JnPsLBTQQTAQIAIwUCVEJ7AwIbAwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEH4VEAzNNmmxNcwOniaZVLsuy1lW/ntYCA0Caz0i sHpmecK8aWlvL9wpQCk4GlOX9L1emyYXZPmzIYB0IRqmSzAlZxi+A2qm9XOxs5gJ2xqMEXX5 FMtUH3kpkWWJeLqe7z0EoQdUI4EG988uv/tdZyqjUn2XJE+K01x7r3MkUSFz/HZKZiCvYuze VlS0NTYdUt5jBXualvAwNKfxEkrxeHjxgdFHjYWhjflahY7TNRmuqPM/Lx7wAuyoDjlYNE40 Z+Kun4/KjMbjgpcF4Nf3PJQR8qXI6p3so2qsSn91tY7DFSJO6v2HwFJkC2jU95wxfNmTEUZc znXahYbVOwCDJRuPrE5GKFd/XJU9u5hNtr/uYipHij01WXal2cce1S5mn1/HuM1yo1u8xdHy IupCd57EWI948e8BlhpujUCU2tzOb2iYS0kpmJ9/oLVZrOcSZCcCl2P0AaCAsj59z2kwQS9D du0WxUs8waso0Qq6tDEHo8yLCOJDzSz4oojTtWe4zsulVnWV+wu70AioemAT8S6JOtlu60C5 dHgQUD1Tp+ReXpDKXmjbASJx4otvW0qah3o6JaqO79tbDqIvncu3tewwp6c85uZd48JnIOh3 utBAu684nJakbbvZUGikJfxd887ATQRUQnHuAQgAx4dxXO6/Zun0eVYOnr5GRl76+2UrAAem Vv9Yfn2PbDIbxXqLff7oyVJIkw4WdhQIIvvtu5zH24iYjmdfbg8iWpP7NqxUQRUZJEWbx2CR wkMHtOmzQiQ2tSLjKh/cHeyFH68xjeLcinR7jXMrHQK+UCEw6jqi1oeZzGvfmxarUmS0uRuf fAb589AJW50kkQK9VD/9QC2FJISSUDnRC0PawGSZDXhmvITJMdD4TjYrePYhSY4uuIV02v02 8TVAaYbIhxvDY0hUQE4r8ZbGRLn52bEzaIPgl1p/adKfeOUeMReg/CkyzQpmyB1TSk8lDMxQ zCYHXAzwnGi8WU9iuE1P0wARAQABwsEzBBgBAgAJBQJUQnHuAhsMAAoJEH4VEAzNNmmxp1EO oJy0uZggJm7gZKeJ7iUpeX4eqUtqelUw6gU2daz2hE/jsxsTbC/w5piHmk1H1VWDKEM4bQBT uiJ0bfo55SWsUNN+c9hhIX+Y8LEe22izK3w7mRpvGcg+/ZRG4DEMHLP6JVsv5GMpoYwYOmHn plOzCXHvmdlW0i6SrMsBDl9rw4AtIa6bRwWLim1lQ6EM3PWifPrWSUPrPcw4OLSwFk0CPqC4 HYv/7ZnASVkR5EERFF3+6iaaVi5OgBd81F1TCvCX2BEyIDRZLJNvX3TOd5FEN+lIrl26xecz 876SvcOb5SL5SKg9/rCBufdPSjojkGFWGziHiFaYhbuI2E+NfWLJtd+ZvWAAV+O0d8vFFSvr iy9enJ8kxJwhC0ECbSKFY+W1eTIhMD3aeAKY90drozWEyHhENf4l/V+Ja5vOnW+gCDQkGt2Y 1lJAPPSIqZKvHzGShdh8DduC0U3xYkfbGAUvbxeepjgzp0uEnBXfPTy09JGpgWbg0w91GyfT /ujKaGd4vxG2Ei+MMNDmS1SMx7wu0evvQ5kT9NPzyq8R2GIhVSiAd2jioGuTjX6AZCFv3ToO 53DliFMkVTecLptsXaesuUHgL9dKIfvpm+rNXRn9wAwGjk0X/A== Message-ID: Date: Mon, 15 Oct 2018 19:12:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181008022532.4ve2xww4yphk6f5d@master> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Mon, 15 Oct 2018 17:12:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/10/2018 04:25, Wei Yang wrote: > On Mon, Oct 08, 2018 at 09:04:34AM +0800, peng.hao2@zte.com.cn wrote: >>> On Sat, Oct 06, 2018 at 11:31:04AM +0800, peng.hao2@zte.com.cn wrote: >>>>> On Thu, Oct 04, 2018 at 01:47:18PM -0400, Peng Hao wrote: >>>>>> >>>>>> From: Peng Hao >>>>>> >>>>>> modify AVIC_LOGICAL_ID_ENTRY_VALID_MASK to unsigned >>>>>> >>>>>> Signed-off-by: Peng Hao >>>>>> --- >>>>>> arch/x86/kvm/svm.c | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >>>>>> index d96092b..bf1ded4 100644 >>>>>> --- a/arch/x86/kvm/svm.c >>>>>> +++ b/arch/x86/kvm/svm.c >>>>>> @@ -262,7 +262,7 @@ struct amd_svm_iommu_ir { >>>>>> }; >>>>>> >>>>>> #define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK (0xFF) >>>>>> -#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK (1 << 31) >>>>>> +#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK (1UL << 31) >>>> >>>>> It is reasonable to change to unsigned, while not necessary to unsigned >>>>> long? >>>> AVIC_LOGICAL_ID_ENTRY_VALID_MASK is used in function avic_ldr_write. >>>> here I think it doesn't matter if you use unsigned or unsigned long. Do you have any suggestions? >> >>> In current case, AVIC_LOGICAL_ID_ENTRY_VALID_MASK is used to calculate >>> the value of new_entry with type of u32. So the definition here is not >>> harmful. >> >>> Also, I did a quick grep and found similar definition (1 << 31) is popular >>> in the whole kernel tree. >> >>> The reason to make this change is not that strong to me. Would you >>> minding sharing more reason behind this change? >> oh, I'm just thinking logically, not more reason. > > This definition may introduce problem when this value is used to > calculate a 64bit data. > > Since current entry is 32bit, we may leave it as it is for now. I agree. Paolo