[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SN6PR02MB415765AAE0196AD2147DFAECD42F2@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Tue, 26 Nov 2024 05:57:56 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>, "linux-arch@...r.kernel.org"
<linux-arch@...r.kernel.org>, "virtualization@...ts.linux.dev"
<virtualization@...ts.linux.dev>
CC: "kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com"
<haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
"decui@...rosoft.com" <decui@...rosoft.com>, "catalin.marinas@....com"
<catalin.marinas@....com>, "will@...nel.org" <will@...nel.org>,
"luto@...nel.org" <luto@...nel.org>, "tglx@...utronix.de"
<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
<bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"seanjc@...gle.com" <seanjc@...gle.com>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "peterz@...radead.org" <peterz@...radead.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>, "joro@...tes.org"
<joro@...tes.org>, "robin.murphy@....com" <robin.murphy@....com>,
"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>, "lpieralisi@...nel.org"
<lpieralisi@...nel.org>, "kw@...ux.com" <kw@...ux.com>, "robh@...nel.org"
<robh@...nel.org>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"arnd@...db.de" <arnd@...db.de>, "sgarzare@...hat.com" <sgarzare@...hat.com>,
"jinankjain@...ux.microsoft.com" <jinankjain@...ux.microsoft.com>,
"muminulrussell@...il.com" <muminulrussell@...il.com>,
"skinsburskii@...ux.microsoft.com" <skinsburskii@...ux.microsoft.com>,
"mukeshrathor@...rosoft.com" <mukeshrathor@...rosoft.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>, "ssengar@...ux.microsoft.com"
<ssengar@...ux.microsoft.com>, "apais@...ux.microsoft.com"
<apais@...ux.microsoft.com>, "eahariha@...ux.microsoft.com"
<eahariha@...ux.microsoft.com>, "horms@...nel.org" <horms@...nel.org>
Subject: RE: [PATCH v3 3/5] hyperv: Add new Hyper-V headers in include/hyperv
From: Nuno Das Neves <nunodasneves@...ux.microsoft.com> Sent: Monday, November 25, 2024 3:25 PM
>
> These headers contain definitions for regular Hyper-V guests (as in
> hyperv-tlfs.h), as well as interfaces for more privileged guests like
> the root partition (aka Dom0).
>
> These files are derived from headers exported from Hyper-V, rather than
> being derived from the TLFS document. (Although, to preserve
> compatibility with existing Linux code, some definitions are copied
> directly from hyperv-tlfs.h too).
>
> The new files follow a naming convention according to their original
> use:
> - hdk "host development kit"
> - gdk "guest development kit"
> With postfix "_mini" implying userspace-only headers, and "_ext" for
> extended hypercalls.
>
> The use of multiple files and their original names is primarily to
> keep the provenance of exactly where they came from in Hyper-V
> code, which is helpful for manual maintenance and extension
> of these definitions. Microsoft maintainers importing new definitions
> should take care to put them in the right file. However, Linux kernel
> code that uses any of the definitions need not be aware of the multiple
> files or assign any meaning to the new names. Linux kernel code should
> always just include hvhdk.h
>
> Note the new headers contain both arm64 and x86_64 definitions. Some are
> guarded by #ifdefs, and some are instead prefixed with the architecture,
> e.g. hv_x64_*. These conventions are kept from Hyper-V code as another
> tactic to simplify the process of importing and maintaining the
> definitions, rather than splitting them up into their own files in
> arch/x86/ and arch/arm64/.
>
> These headers are a step toward importing headers directly from Hyper-V
> in the future, similar to Xen public files in include/xen/interface/.
>
> Signed-off-by: Nuno Das Neves <nunodasneves@...ux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@...look.com>
Powered by blists - more mailing lists