From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28]) by dpdk.org (Postfix) with ESMTP id BB02E3255
for <dev@dpdk.org>; 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: <xms:SxghWlqY9NtEGr1PyWosKZEvcf1s6G0qCitfMvdOf8lTIvUj4VrpPw>
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 <thomas@monjalon.net>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <thomas@monjalon.net>
> > 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 <sthemmin@microsoft.com>
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > 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.