From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 73CA62C07 for ; Tue, 23 Aug 2016 16:05:51 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3BE44E4E0; Tue, 23 Aug 2016 14:05:50 +0000 (UTC) Received: from [10.36.4.245] (vpn1-4-245.ams2.redhat.com [10.36.4.245]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7NE5mDG027536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2016 10:05:50 -0400 To: Yuanhan Liu References: <1471939839-29778-1-git-send-email-yuanhan.liu@linux.intel.com> <1471939839-29778-3-git-send-email-yuanhan.liu@linux.intel.com> <13f37c6e-b389-a758-81cd-861db7337e1f@redhat.com> <20160823123211.GK30752@yliu-dev.sh.intel.com> <713fbf24-b451-5ffa-0bdf-e8d1a8624bcb@redhat.com> <20160823134924.GN30752@yliu-dev.sh.intel.com> Cc: dev@dpdk.org From: Maxime Coquelin Message-ID: Date: Tue, 23 Aug 2016 16:05:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160823134924.GN30752@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 23 Aug 2016 14:05:50 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 2/6] vhost: get guest/host physical address mappings 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, 23 Aug 2016 14:05:51 -0000 On 08/23/2016 03:49 PM, Yuanhan Liu wrote: > On Tue, Aug 23, 2016 at 03:25:33PM +0200, Maxime Coquelin wrote: >> >> >> On 08/23/2016 02:32 PM, Yuanhan Liu wrote: >>>>> + >>>>>>> + /* FIXME */ >>>>>>> + RTE_LOG(INFO, VHOST_CONFIG, ":: %u ::\n", pre_read); >>>>> For my information, what is the purpose of pre_read? >>> Again, I put a FIXME here, but I forgot to add some explanation. >>> >>> Here is the thing: the read will make sure the kernel populate the >>> corresponding PTE entry, so that rte_mem_virt2phy() will return proper >>> physical address, otherwise, invalid value is returned. >>> >>> I can't simply do the read but do not actually reference/consume it. >>> Otherwise, the compiler will treat it as some noops and remove it. >>> >>> An ugly RTE_LOG will make sure the read operation is not eliminated. >>> I'm seeking a more proper way to achieve that. Maybe I can add a new >>> field in virtio_net structure and store it there. >>> >>> Or, do you have better ideas? >> >> This behavior is pretty twisted, no? > > I have to say, yes, kind of. > >> Shouldn't be rte_mem_virt2phy() role to ensure returning a valid value? > > Not exactly. I think rte_mem_virt2phy() is more likely to fetch the > physical address of huge pages. And for those huge pages, EAL makes > sure they will be populated: it used to do a zero memset before to > achieve that. Since 5ce3ace1de45 ("eal: remove unnecessary hugepage > zero-filling"), it uses MAP_POPULATE option instead. > > So, thank you that you just remind me of the MAP_POPULATE option. > I just had a quick try, it worked like a charm :) Excellent! :)