Re: [PATCH 10/13] x86/tdx: Convert shared memory back to private on kexec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 10/6/2023 10:11 AM, Kirill A. Shutemov wrote:
On Fri, Oct 06, 2023 at 07:58:03AM -0700, Sean Christopherson wrote:
On Thu, Oct 05, 2023, Kirill A. Shutemov wrote:
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7368d254d01f..b5acf9fb4c70 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -884,6 +884,7 @@ config INTEL_TDX_GUEST
  	select X86_MEM_ENCRYPT
  	select X86_MCE
  	select UNACCEPTED_MEMORY
+	select EMERGENCY_VIRT_CALLBACK
  	help
  	  Support running as a guest under Intel TDX.  Without this support,
  	  the guest kernel can not boot or run under TDX.

...

  void __init tdx_early_init(void)
  {
  	struct tdx_module_args args = {
@@ -882,6 +1007,14 @@ void __init tdx_early_init(void)
  	 */
  	x86_cpuinit.parallel_bringup = false;
+ machine_ops.shutdown = tdx_shutdown;
+
+	/*
+	 * KVM overrides machine_ops.crash_shutdown, use emergency

This is going to be super confusing.  KVM utilizes the emergency virt callback.
The KVM paravirt guest code uses .crash_shutdown().  People that are passingly
familiar with virt and know what KVM is, but don't already know the difference
between the two are going to be all kinds of confused.

I also feel like you're playing with fire, e.g. what's to stop the hypervisor
specific paravirt guest support from using .shutdown() in the future?

And the callback is invoked for far more than just kexec().  I don't see how the
host can emulate a reboot without destroying and rebuilding the VM, e.g. it can't
stuff register state to emulate INIT or RESET.  Unless I'm missing something,
converting shared memory back to private for a shutdown or reboot is undesirable
as adds one more thing that can go wrong and prevent the system from cleanly
shutting down ASAP (for some definitions of "cleanly").

Okay, fair enough. I will look for better way to hookup into kexec
process. That was the best fit I found so far, but yes it is not ideal.

Lastly, doesn't SEV need similar behavior?  This seems like core functionality
for any guest with cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT).  Why not make the
"unshare on kexec" code common and gate it with CC_ATTR_GUEST_MEM_ENCRYPT?

I don't know SEV specifics. I am open to collaboration on this.

Tom, Ashish, let me know if you need this in generic code. I can arrange
that.


Yes, some kind of a generic interface like unshare_on_kexec() gated with CC_ATTR_GUEST_MEM_ENCRYPT is needed, we can then add SNP specific kexec functionality as part of this.

Thanks,
Ashish

_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux