From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id BB02E3255 for ; Fri, 1 Dec 2017 09:52:28 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 123E920DCF; Fri, 1 Dec 2017 03:52:28 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 01 Dec 2017 03:52:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=KytsZtq3QssiFQuwkwqLNUyXGf FJSVBpD1vbgdK0ytI=; b=Mm+ZjaIOApcH511nlUCveDqf7XTF1X5PBvpTM2p2LW zd1u2RLxVOjOEylvNbDrRtnfNR+8B5ALAuxoHmgKNyg9i9QhpGBXqjrvYe2qX/5u YMmQ679K5kLmmjPJiC9IvuPyGXbTXgDF6NKk3vfenh7KusBJjkFPwZT4YJhs/RXp c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KytsZt q3QssiFQuwkwqLNUyXGfFJSVBpD1vbgdK0ytI=; b=W1lIDFyc6jK2/TTyfYXyLB N7sfvnUiZZzCqWYldHye08DWXDkSFO9RAocrv5m+rDiX780/7rBs9GerP0FC9XMb 7Lyb9sRqYUqACr2ZOmbYzcWhRwdIU85+Yb+q1XU0seShAO60BeLlS/PjmuevTKiY t5SKPz5o95qs0O2jOAMUY65nXsNrGEZrqUrsr52pSB6w0yS79jTtlLeAE0r/8bkG KDk+6jegBpqFKc2zO1w9LXuoJeX4abr/FXalXJdWBPgP/DVm3pXhp7FH0g88m1yJ SY4RsnnTJu+wP016J5edBZw/27904XJC/P/MBbFyQQnsBddj+pwBWPvaC9sT9D4g == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AF55324A6C; Fri, 1 Dec 2017 03:52:27 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob Cc: dev@dpdk.org, chaozhu@linux.vnet.ibm.com Date: Fri, 01 Dec 2017 09:52:26 +0100 Message-ID: <9012196.L72nSLPZ2J@xps> In-Reply-To: <20171201081234.GA24936@jerin> References: <20171130214720.30098-1-thomas@monjalon.net> <20171201081234.GA24936@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal/x86: get hypervisor name X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 08:52:29 -0000 01/12/2017 09:12, Jerin Jacob: > -----Original Message----- > > Date: Thu, 30 Nov 2017 22:47:20 +0100 > > From: Thomas Monjalon > > To: dev@dpdk.org > > Subject: [dpdk-dev] [PATCH] eal/x86: get hypervisor name > > X-Mailer: git-send-email 2.15.0 > > > > The CPUID instruction is catched by hypervisor which can return > > a flag indicating one is running, and its name. > > > > Suggested-by: Stephen Hemminger > > Signed-off-by: Thomas Monjalon > > --- > > warning: to be tested > > --- > > lib/librte_eal/common/arch/arm/rte_cpuflags.c | 6 +++++ > > lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 6 +++++ > > lib/librte_eal/common/arch/x86/rte_cpuflags.c | 30 ++++++++++++++++++++++ > > .../common/include/arch/x86/rte_cpuflags.h | 1 + > > .../common/include/generic/rte_cpuflags.h | 14 ++++++++++ > > lib/librte_eal/rte_eal_version.map | 9 ++++++- > > 6 files changed, 65 insertions(+), 1 deletion(-) > > RTE_CPUFLAG_FPU, /**< FPU */ > > diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h b/lib/librte_eal/common/include/generic/rte_cpuflags.h > > index c1c5551fc..3832fb851 100644 > > --- a/lib/librte_eal/common/include/generic/rte_cpuflags.h > > +++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h > > @@ -93,4 +93,18 @@ rte_cpu_check_supported(void); > > int > > rte_cpu_is_supported(void); > > > > +enum rte_hypervisor { > > + RTE_HYPERVISOR_NONE, > > + RTE_HYPERVISOR_KVM, > > + RTE_HYPERVISOR_HYPERV, > > + RTE_HYPERVISOR_VMWARE, > > + RTE_HYPERVISOR_UNKNOWN > > +}; > > + > > +/** > > + * Get the type of hypervisor it is running on. > > + */ > > +enum rte_hypervisor > > +rte_hypervisor_get_name(void); > > Cc: chaozhu@linux.vnet.ibm.com > > IMO, cpu_flag area is the not the correct abstraction to get > the hypervisor name. It is x86 specific. I think, correct > usage will be to call hypervisor specific APIs like KVM_GET_API_VERSION > https://lwn.net/Articles/658511/ I think it is quite logical because the CPU is virtualized by the hypervisor. It is similar to get the CPU model, but for a different ring level. > BTW, What is the need for an DPDK application to know the > hypervisor name? What action an DPDK application should > take based on hypervisor name? if is not interest of data plane > application why it needs to be abstracted in DPDK? I see two usages for now. We can automate the use of the specific VMware TSC (it is an option currently). We can adapt the device management policy on Hyper-V without waiting a device scan.