Hi Stephen,

Do you see any problem of preventing your patch of "xen: allow choosing dom0 support at runtime" into upcoming 2.1 release? It will be better that fm10k's XEN support can base on your modifications, and I will rework this fm10k patch.

But in case your patch cannot make it into 2.1, to enable users to use fm10k with XEN domain0 in next release, should we enable this function by using current approach first?

Thanks,
--Shaopeng

-----Original Message-----
From: Liu, Jijiang 
Sent: Monday, May 18, 2015 10:23 AM
To: Stephen Hemminger; He, Shaopeng; Thomas Monjalon
Cc: dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH] fm10k: support XEN domain0

Hi guys,

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Saturday, May 16, 2015 7:58 AM
To: He, Shaopeng
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] fm10k: support XEN domain0

On Fri, 15 May 2015 16:56:02 +0800
Shaopeng He [off-list ref] wrote:

quoted

fm10k was failing to run in XEN domain0, as the physical memory for 
DMA should be allocated and translated in a different way for XEN 
domain0. So
rte_memzone_reserve_bounded() should be used for DMA memory 
allocation, and rte_mem_phy2mch() should be used for DMA memory 
address translation to support running fm10k PMD in XEN domain0.

Signed-off-by: Shaopeng He <redacted>

I agree with Thomas that this code has spread everywhere and should be 
in a common spot.

Also, we discovered as part of the Xen net-front driver that it should 
be a runtime determination, not a config option!

I also agree that it should be in a common spot.
But  it had better to apply the following Stephen's patch first. If so, Shaopeng just use the common function in the patch, which would be good.  
http://dpdk.org/ml/archives/dev/2015-March/014992.html