From: Wei Liu <wei.liu@kernel.org>
To: Michael Kelley <mikelley@microsoft.com>
Cc: kys@microsoft.com, haiyangz@microsoft.com,
sthemmin@microsoft.com, wei.liu@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
pbonzini@redhat.com, sean.j.christopherson@intel.com,
vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com,
joro@8bytes.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH v2 0/4] Split hyperv-tlfs.h into generic and arch specific files
Date: Thu, 23 Apr 2020 13:22:08 +0000 [thread overview]
Message-ID: <20200423132208.i522jqpevglruhur@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> (raw)
In-Reply-To: <20200422195737.10223-1-mikelley@microsoft.com>
On Wed, Apr 22, 2020 at 12:57:33PM -0700, Michael Kelley wrote:
> This series splits hyperv-tlfs.h into architecture independent and
> architecture specific files so that the arch independent portion can
> be shared between the x86/x64 and ARM64 code for Hyper-V. While the
> Hyper-V team has not released a version of the TLFS document that
> clearly specifies which portions of the interface are arch independent,
> we can make a fairly good assessment based on implementation work done
> to support Linux guests on Hyper-V on ARM64, and on private communication
> with the Hyper-V team. Definitions are considered arch independent if
> they are implemented by Hyper-V on both architectures (x86/x64 and ARM64),
> even if they are currently needed by Linux code only on one architecture.
>
> Many definitions in hyperv-tlfs.h have historically contained "X64" in the
> name, which doesn't make sense for architecture independent definitions.
> While many of the occurrences of "X64" have already been removed, some
> still remain in definitions that should be arch independent. The
> split removes the "X64" from the definitions so that the arch
> independent hyper-tlfs.h has no occurrences of "X64". However, to
> keep this patch set separate from a wider change in the names, aliases
> are added in the x86/x64 specific hyperv-tlfs.h so that existing code
> continues to compile. The definitions can be fixed throughout the code
> in a more incremental fashion in separate patches, and then the aliases
> can be removed.
>
> Where it is not clear if definitions are arch independent, they have been
> kept in the x86/x64 specific file. The Hyper-V team is aiming to have a
> version of the TLFS document covering ARM64 by the end of calendar 2020,
> so additional definitions may be moved into the arch independent portion
> after the new TLFS document is released.
>
> The first two patches in the series clean up the existing hyperv-tlfs.h
> file a bit by removing duplicate or unnecessary definitions so they are
> not propagated across the split. The third patch does the split, and the
> fourth patch adds new definitions that are needed on ARM64 but are generic.
>
> These changes have no functional impact.
>
> These patches are built against linux-next-20200415
Applied to hyperv-next. Thanks.
Wei.
prev parent reply other threads:[~2020-04-23 13:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 19:57 [PATCH v2 0/4] Split hyperv-tlfs.h into generic and arch specific files Michael Kelley
2020-04-22 19:57 ` [PATCH v2 1/4] KVM: x86: hyperv: Remove duplicate definitions of Reference TSC Page Michael Kelley
2020-04-22 19:57 ` [PATCH v2 2/4] x86/hyperv: Remove HV_PROCESSOR_POWER_STATE #defines Michael Kelley
2020-04-22 19:57 ` [PATCH v2 3/4] x86/hyperv: Split hyperv-tlfs.h into arch dependent and independent files Michael Kelley
2020-04-22 19:57 ` [PATCH v2 4/4] asm-generic/hyperv: Add definitions for Get/SetVpRegister hypercalls Michael Kelley
2020-04-23 9:46 ` Vitaly Kuznetsov
2020-04-23 13:22 ` Wei Liu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200423132208.i522jqpevglruhur@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net \
--to=wei.liu@kernel.org \
--cc=bp@alien8.de \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).