Hi Linus,
The following changes since commit 64570fbc14f8d7cb3fe3995f20e26bc25ce4b2cc:
Linux 5.15-rc5 (2021-10-10 17:01:59 -0700)
are available in the Git repository at:
ssh://[email protected]/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed-20211102
for you to fetch changes up to 285f68afa8b20f752b0b7194d54980b5e0e27b75:
x86/hyperv: Protect set_hv_tscchange_cb() against getting preempted (2021-10-28 11:59:13 +0000)
There are two merges from the tip tree: one is because of Tianyu's
patches went in via tip/x86/sev, the other is because a tree-wide
cleanup in tip/x86/cc conflicted with Tianyu's patch.
Instead of requiring you to fix up I thought I'd just do it myself.
Thanks,
Wei.
----------------------------------------------------------------
hyperv-next for 5.16
- Initial patch set for Hyper-V isolation VM support (Tianyu Lan)
- Fix a warning on preemption (Vitaly Kuznetsov)
- A bunch of misc cleanup patches.
----------------------------------------------------------------
Jiapeng Chong (1):
x86/hyperv: Remove duplicate include
Lv Ruyi (1):
Drivers: hv : vmbus: Adding NULL pointer check
Michael Kelley (1):
Drivers: hv: vmbus: Remove unused code to check for subchannels
Tianyu Lan (9):
x86/sev: Expose sev_es_ghcb_hv_call() for use by HyperV
x86/hyperv: Initialize GHCB page in Isolation VM
x86/hyperv: Initialize shared memory boundary in the Isolation VM.
x86/hyperv: Add new hvcall guest address host visibility support
Drivers: hv: vmbus: Mark vmbus ring buffer visible to host in Isolation VM
x86/hyperv: Add Write/Read MSR registers via ghcb page
x86/hyperv: Add ghcb hvcall support for SNP VM
Drivers: hv: vmbus: Add SNP support for VMbus channel initiate message
Drivers: hv: vmbus: Initialize VMbus ring buffer for Isolation VM
Vitaly Kuznetsov (1):
x86/hyperv: Protect set_hv_tscchange_cb() against getting preempted
Wan Jiabing (1):
x86/hyperv: Remove duplicated include in hv_init
Wei Liu (2):
Merge remote-tracking branch 'tip/x86/sev' into hyperv-next
Merge remote-tracking branch 'tip/x86/cc' into hyperv-next
arch/Kconfig | 3 +
arch/powerpc/include/asm/mem_encrypt.h | 5 -
arch/powerpc/platforms/pseries/Kconfig | 1 +
arch/powerpc/platforms/pseries/Makefile | 2 +
arch/powerpc/platforms/pseries/cc_platform.c | 26 +++
arch/powerpc/platforms/pseries/svm.c | 5 +-
arch/s390/include/asm/mem_encrypt.h | 2 -
arch/x86/Kconfig | 1 +
arch/x86/hyperv/Makefile | 2 +-
arch/x86/hyperv/hv_init.c | 82 ++++++--
arch/x86/hyperv/ivm.c | 289 +++++++++++++++++++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 17 ++
arch/x86/include/asm/io.h | 8 +
arch/x86/include/asm/kexec.h | 2 +-
arch/x86/include/asm/mem_encrypt.h | 12 +-
arch/x86/include/asm/mshyperv.h | 70 +++++--
arch/x86/include/asm/sev.h | 6 +
arch/x86/kernel/Makefile | 6 +
arch/x86/kernel/cc_platform.c | 69 +++++++
arch/x86/kernel/cpu/mshyperv.c | 5 +
arch/x86/kernel/crash_dump_64.c | 4 +-
arch/x86/kernel/head64.c | 9 +-
arch/x86/kernel/kvm.c | 3 +-
arch/x86/kernel/kvmclock.c | 4 +-
arch/x86/kernel/machine_kexec_64.c | 19 +-
arch/x86/kernel/pci-swiotlb.c | 9 +-
arch/x86/kernel/relocate_kernel_64.S | 2 +-
arch/x86/kernel/sev-shared.c | 68 ++++---
arch/x86/kernel/sev.c | 40 ++--
arch/x86/kernel/traps.c | 2 +-
arch/x86/kvm/svm/svm.c | 3 +-
arch/x86/mm/ioremap.c | 18 +-
arch/x86/mm/mem_encrypt.c | 55 ++---
arch/x86/mm/mem_encrypt_identity.c | 18 +-
arch/x86/mm/pat/set_memory.c | 24 ++-
arch/x86/platform/efi/efi_64.c | 9 +-
arch/x86/realmode/init.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
drivers/gpu/drm/drm_cache.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +-
drivers/hv/Kconfig | 1 +
drivers/hv/channel.c | 72 ++++---
drivers/hv/channel_mgmt.c | 34 ----
drivers/hv/connection.c | 101 +++++++++-
drivers/hv/hv.c | 82 ++++++--
drivers/hv/hv_common.c | 12 ++
drivers/hv/hyperv_vmbus.h | 2 +
drivers/hv/ring_buffer.c | 57 ++++--
drivers/iommu/amd/init.c | 7 +-
drivers/iommu/amd/iommu.c | 3 +-
drivers/iommu/amd/iommu_v2.c | 3 +-
drivers/iommu/iommu.c | 3 +-
drivers/net/hyperv/hyperv_net.h | 5 +-
drivers/net/hyperv/netvsc.c | 15 +-
drivers/uio/uio_hv_generic.c | 18 +-
fs/proc/vmcore.c | 6 +-
include/asm-generic/hyperv-tlfs.h | 1 +
include/asm-generic/mshyperv.h | 20 +-
include/linux/cc_platform.h | 88 ++++++++
include/linux/hyperv.h | 25 +--
include/linux/mem_encrypt.h | 4 -
kernel/dma/swiotlb.c | 4 +-
63 files changed, 1150 insertions(+), 339 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c
create mode 100644 arch/x86/hyperv/ivm.c
create mode 100644 arch/x86/kernel/cc_platform.c
create mode 100644 include/linux/cc_platform.h
On Tue, Nov 2, 2021 at 6:13 AM Wei Liu <[email protected]> wrote:
>
> There are two merges from the tip tree: one is because of Tianyu's
> patches went in via tip/x86/sev, the other is because a tree-wide
> cleanup in tip/x86/cc conflicted with Tianyu's patch.
>
> Instead of requiring you to fix up I thought I'd just do it myself.
Please don't do that.
Merging a pre-requisite and having a common branch that you merge - that's fine.
But don't hide merge conflicts from me by "pre-merging". It's not helpful.
And to make matters worse, both of those merges are BAD.
They have absolutely no explanation.
Christ.
For the millionth time:
IF YOU CAN'T BE BOTHERED TO WRITE A PROPER COMMIT MESSAGE FOR A
MERGE, DON'T DO THE MERGE
I'm getting really tired of having to say this multiple times every
merge window (and often in between merge windows too).
Your merges are bad, and you should feel bad.
I've pulled this, but at some point I'm just going to have to decide
that "bad merges means I will not pull your garbage".
Merges need commit messages that explain what is going on, just as
much as any other commit does.
In fact, arguably they need *more* explanation, since they are subtler
and don't have the obvious patch associated with them that may clarify
what is going on.
So a merge message like
Merge remote-tracking branch 'tip/x86/sev' into hyperv-next
is *NOT* an acceptable merge message. It needs an explanation of what
that SEV branch contained, and *WHY* those contents needed to be
merged into hyperv-next.
Again: if you can't explain the merge, or you can't be bothered, just
DON'T DO IT.
And no, the "hide conflicts from Linus" is _not_ an acceptable reason
to do merges.
I do so many merges that I can do most conflicts in my sleep, and
often do them as well or better than the submaintainers do. And I
write proper merge messages, and when a conflict happens it means I
*know* about it and am aware of how different trees ended up
interacting with each other - all of which is good.
Again - I've taken this pull request, but I'm not happy about those
merges. Even the merge that was perfectly fine to do wasn't done well.
Linus
On Tue, Nov 02, 2021 at 11:11:29AM -0700, Linus Torvalds wrote:
> On Tue, Nov 2, 2021 at 6:13 AM Wei Liu <[email protected]> wrote:
> >
> > There are two merges from the tip tree: one is because of Tianyu's
> > patches went in via tip/x86/sev, the other is because a tree-wide
> > cleanup in tip/x86/cc conflicted with Tianyu's patch.
> >
> > Instead of requiring you to fix up I thought I'd just do it myself.
>
> Please don't do that.
>
> Merging a pre-requisite and having a common branch that you merge - that's fine.
>
> But don't hide merge conflicts from me by "pre-merging". It's not helpful.
>
> And to make matters worse, both of those merges are BAD.
>
> They have absolutely no explanation.
>
> Christ.
>
> For the millionth time:
>
> IF YOU CAN'T BE BOTHERED TO WRITE A PROPER COMMIT MESSAGE FOR A
> MERGE, DON'T DO THE MERGE
>
> I'm getting really tired of having to say this multiple times every
> merge window (and often in between merge windows too).
>
> Your merges are bad, and you should feel bad.
>
> I've pulled this, but at some point I'm just going to have to decide
> that "bad merges means I will not pull your garbage".
>
> Merges need commit messages that explain what is going on, just as
> much as any other commit does.
>
> In fact, arguably they need *more* explanation, since they are subtler
> and don't have the obvious patch associated with them that may clarify
> what is going on.
>
> So a merge message like
>
> Merge remote-tracking branch 'tip/x86/sev' into hyperv-next
>
> is *NOT* an acceptable merge message. It needs an explanation of what
> that SEV branch contained, and *WHY* those contents needed to be
> merged into hyperv-next.
>
> Again: if you can't explain the merge, or you can't be bothered, just
> DON'T DO IT.
>
> And no, the "hide conflicts from Linus" is _not_ an acceptable reason
> to do merges.
>
> I do so many merges that I can do most conflicts in my sleep, and
> often do them as well or better than the submaintainers do. And I
> write proper merge messages, and when a conflict happens it means I
> *know* about it and am aware of how different trees ended up
> interacting with each other - all of which is good.
>
> Again - I've taken this pull request, but I'm not happy about those
> merges. Even the merge that was perfectly fine to do wasn't done well.
>
Okay. Noted. Thanks for pulling in those patches. I will keep what you
said above in mind for future PRs.
Wei.
> Linus
The pull request you sent on Tue, 2 Nov 2021 13:13:09 +0000:
> ssh://[email protected]/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed-20211102
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44261f8e287d1b02a2e4bfbd7399fb8d37d1ee24
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html