From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id E03B48E94 for ; Tue, 19 Jan 2016 03:48:54 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 18 Jan 2016 18:48:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,315,1449561600"; d="scan'208";a="896079187" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 18 Jan 2016 18:48:43 -0800 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 18 Jan 2016 18:48:41 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 18 Jan 2016 18:48:41 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.215]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.218]) with mapi id 14.03.0248.002; Tue, 19 Jan 2016 10:48:39 +0800 From: "Xie, Huawei" To: Yuanhan Liu Thread-Topic: [PATCH v4 7/8] virtio: add 1.0 support Thread-Index: AdFSEsO9024IClH9QuSR9YlAzWxVyw== Date: Tue, 19 Jan 2016 02:48:39 +0000 Message-ID: References: <1452581944-24838-1-git-send-email-yuanhan.liu@linux.intel.com> <1452832571-6156-1-git-send-email-yuanhan.liu@linux.intel.com> <1452832571-6156-8-git-send-email-yuanhan.liu@linux.intel.com> <20160119013659.GF19531@yliu-dev.sh.intel.com> <20160119024603.GG19531@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.4.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v4 7/8] virtio: add 1.0 support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 02:48:55 -0000 On 1/19/2016 10:44 AM, Yuanhan Liu wrote:=0A= > On Tue, Jan 19, 2016 at 01:51:30AM +0000, Xie, Huawei wrote:=0A= >> On 1/19/2016 9:34 AM, Yuanhan Liu wrote:=0A= >>> On Mon, Jan 18, 2016 at 05:07:51PM +0000, Xie, Huawei wrote:=0A= >>>> .On 1/15/2016 12:34 PM, Yuanhan Liu wrote:=0A= >>>>> Modern (v1.0) virtio pci device defines several pci capabilities.=0A= >>>>> Each cap has a configure structure corresponding to it, and the=0A= >>>>> cap.bar and cap.offset fields tell us where to find it.=0A= >>>>>=0A= >>>> [snip]=0A= >>>>> +=0A= >>>>> +static inline void=0A= >>>>> +io_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi)=0A= >>>>> +{=0A= >>>>> + io_write32((uint32_t)val, lo);=0A= >>>>> + io_write32(val >> 32, hi);=0A= >>>> Firstly your second iowrite32 doesn't do the conversion.=0A= >>> Because it's not necessary. The first one is for retrieving the low 32= =0A= >>> bits.=0A= >> I don't mean the shift operation, but the conversion from 64bit to 32bit= .=0A= >> Same applied to below.=0A= > It's more than a casting here: it's same as "val & (1<<32 - 1)", as=0A= > stated above, to retrieve the low 32 bits.=0A= >=0A= > I know it still could work without it, but, hey, what's wrong to make=0A= > it explicit?=0A= =0A= Say x =3D val, y =3D val >> 32, both with (uint32_t) or both not. Be=0A= consistent and simple.=0A= =0A= >=0A= > --yliu=0A= >=0A= =0A=