> Currently kexec() support and TDX host are muturally exclusive in the > Kconfig. This series adds the TDX host kexec support so that they can > work together and can be enabled at the same time in the Kconfig. I tried testing the kexec functionality and noticed that the TDX module fails initialization on the second kernel so you can't actually kexec between 2 kernels that enable TDX. Is that the expected behavior? Are there future patches to enable that functionality?
On 20/08/2024 9:21 am, Sagi Shahar wrote: >> Currently kexec() support and TDX host are muturally exclusive in the >> Kconfig. This series adds the TDX host kexec support so that they can >> work together and can be enabled at the same time in the Kconfig. > > I tried testing the kexec functionality and noticed that the TDX module > fails initialization on the second kernel so you can't actually kexec > between 2 kernels that enable TDX. Is that the expected behavior? Are > there future patches to enable that functionality? > Thanks for testing! Yes this is the expected behaviour. If the first kernel has enabled TDX, then the second kernel will fail to init TDX. The reason the first SEAMCALL to initialize TDX module in the second kernel will fail due to module having been initialized. However if the first kernel has not enabled TDX, the second kernel is able to enable it.
On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > On 20/08/2024 9:21 am, Sagi Shahar wrote: > >> Currently kexec() support and TDX host are muturally exclusive in the > >> Kconfig. This series adds the TDX host kexec support so that they can > >> work together and can be enabled at the same time in the Kconfig. > > > > I tried testing the kexec functionality and noticed that the TDX module > > fails initialization on the second kernel so you can't actually kexec > > between 2 kernels that enable TDX. Is that the expected behavior? Are > > there future patches to enable that functionality? > > > > Thanks for testing! > > Yes this is the expected behaviour. If the first kernel has enabled > TDX, then the second kernel will fail to init TDX. The reason the first > SEAMCALL to initialize TDX module in the second kernel will fail due to > module having been initialized. > > However if the first kernel has not enabled TDX, the second kernel is > able to enable it. Are there any plans to support both kernels being able to enable TDX in the future? Either by changes to KVM or the TDX module?
On 20/08/2024 10:28 am, Sagi Shahar wrote: > On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@intel.com> wrote: >> >> >> >> On 20/08/2024 9:21 am, Sagi Shahar wrote: >>>> Currently kexec() support and TDX host are muturally exclusive in the >>>> Kconfig. This series adds the TDX host kexec support so that they can >>>> work together and can be enabled at the same time in the Kconfig. >>> >>> I tried testing the kexec functionality and noticed that the TDX module >>> fails initialization on the second kernel so you can't actually kexec >>> between 2 kernels that enable TDX. Is that the expected behavior? Are >>> there future patches to enable that functionality? >>> >> >> Thanks for testing! >> >> Yes this is the expected behaviour. If the first kernel has enabled >> TDX, then the second kernel will fail to init TDX. The reason the first >> SEAMCALL to initialize TDX module in the second kernel will fail due to >> module having been initialized. >> >> However if the first kernel has not enabled TDX, the second kernel is >> able to enable it. > > Are there any plans to support both kernels being able to enable TDX > in the future? Either by changes to KVM or the TDX module? AFAICT we haven't received such requirement so far. Let me double check internally and get back here. Btw, if we want to do this purely from software, changing KVM isn't the right thing to do. We need to somehow pass key data structures managing TDX module to the second kernel, e.g., module status, locations of PAMTs. And the second kernel needs to be modified to understand those, which means some old (second) kernels with TDX support may not be able to support this even if we add this to the kernel.
On Mon, Aug 19, 2024 at 5:44 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > On 20/08/2024 10:28 am, Sagi Shahar wrote: > > On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@intel.com> wrote: > >> > >> > >> > >> On 20/08/2024 9:21 am, Sagi Shahar wrote: > >>>> Currently kexec() support and TDX host are muturally exclusive in the > >>>> Kconfig. This series adds the TDX host kexec support so that they can > >>>> work together and can be enabled at the same time in the Kconfig. > >>> > >>> I tried testing the kexec functionality and noticed that the TDX module > >>> fails initialization on the second kernel so you can't actually kexec > >>> between 2 kernels that enable TDX. Is that the expected behavior? Are > >>> there future patches to enable that functionality? > >>> > >> > >> Thanks for testing! > >> > >> Yes this is the expected behaviour. If the first kernel has enabled > >> TDX, then the second kernel will fail to init TDX. The reason the first > >> SEAMCALL to initialize TDX module in the second kernel will fail due to > >> module having been initialized. > >> > >> However if the first kernel has not enabled TDX, the second kernel is > >> able to enable it. > > > > Are there any plans to support both kernels being able to enable TDX > > in the future? Either by changes to KVM or the TDX module? > > AFAICT we haven't received such requirement so far. Let me double check > internally and get back here. > > Btw, if we want to do this purely from software, changing KVM isn't the > right thing to do. We need to somehow pass key data structures managing > TDX module to the second kernel, e.g., module status, locations of > PAMTs. And the second kernel needs to be modified to understand those, > which means some old (second) kernels with TDX support may not be able > to support this even if we add this to the kernel. Would it be possible to tear down the tdx module and re-initialize it on the next kernel? I don't think there's a requirement for the tdx module data structures to remain intact during kexec but it could be useful if tdx can be enabled on the new kernel.
On Fri, 2024-08-23 at 11:15 -0500, Sagi Shahar wrote: > On Mon, Aug 19, 2024 at 5:44 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > > > > > On 20/08/2024 10:28 am, Sagi Shahar wrote: > > > On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > > > > > > > > > > > > > On 20/08/2024 9:21 am, Sagi Shahar wrote: > > > > > > Currently kexec() support and TDX host are muturally exclusive in the > > > > > > Kconfig. This series adds the TDX host kexec support so that they can > > > > > > work together and can be enabled at the same time in the Kconfig. > > > > > > > > > > I tried testing the kexec functionality and noticed that the TDX module > > > > > fails initialization on the second kernel so you can't actually kexec > > > > > between 2 kernels that enable TDX. Is that the expected behavior? Are > > > > > there future patches to enable that functionality? > > > > > > > > > > > > > Thanks for testing! > > > > > > > > Yes this is the expected behaviour. If the first kernel has enabled > > > > TDX, then the second kernel will fail to init TDX. The reason the first > > > > SEAMCALL to initialize TDX module in the second kernel will fail due to > > > > module having been initialized. > > > > > > > > However if the first kernel has not enabled TDX, the second kernel is > > > > able to enable it. > > > > > > Are there any plans to support both kernels being able to enable TDX > > > in the future? Either by changes to KVM or the TDX module? > > > > AFAICT we haven't received such requirement so far. Let me double check > > internally and get back here. > > > > Btw, if we want to do this purely from software, changing KVM isn't the > > right thing to do. We need to somehow pass key data structures managing > > TDX module to the second kernel, e.g., module status, locations of > > PAMTs. And the second kernel needs to be modified to understand those, > > which means some old (second) kernels with TDX support may not be able > > to support this even if we add this to the kernel. > > Would it be possible to tear down the tdx module and re-initialize it > on the next kernel? I don't think there's a requirement for the tdx > module data structures to remain intact during kexec but it could be > useful if tdx can be enabled on the new kernel. We discussed this internally. The TDX module cannot be re-initialized after torn down. However the new kernel can reload the (same) TDX module and re- initialize it (the P-SEAMLDR supports reload or runtime update TDX module). However our primary focus is to enable baseline TDX support in upstream. For TDX host kexec, at this stage we focus on: 1) enable both TDX and Kexec in the Kconfig; 2) allow normal kexec and kdump to work when TDX is enabled. Making the second kernel be able to use TDX is next-step plan. May I ask is there any real use case that requires the second kernel to be able to use TDX at this stage?
On Sat, Aug 24, 2024 at 4:31 AM Huang, Kai <kai.huang@intel.com> wrote: > > On Fri, 2024-08-23 at 11:15 -0500, Sagi Shahar wrote: > > On Mon, Aug 19, 2024 at 5:44 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > > > > > > > > > On 20/08/2024 10:28 am, Sagi Shahar wrote: > > > > On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > > > > > > > > > > > > > > > > > On 20/08/2024 9:21 am, Sagi Shahar wrote: > > > > > > > Currently kexec() support and TDX host are muturally exclusive in the > > > > > > > Kconfig. This series adds the TDX host kexec support so that they can > > > > > > > work together and can be enabled at the same time in the Kconfig. > > > > > > > > > > > > I tried testing the kexec functionality and noticed that the TDX module > > > > > > fails initialization on the second kernel so you can't actually kexec > > > > > > between 2 kernels that enable TDX. Is that the expected behavior? Are > > > > > > there future patches to enable that functionality? > > > > > > > > > > > > > > > > Thanks for testing! > > > > > > > > > > Yes this is the expected behaviour. If the first kernel has enabled > > > > > TDX, then the second kernel will fail to init TDX. The reason the first > > > > > SEAMCALL to initialize TDX module in the second kernel will fail due to > > > > > module having been initialized. > > > > > > > > > > However if the first kernel has not enabled TDX, the second kernel is > > > > > able to enable it. > > > > > > > > Are there any plans to support both kernels being able to enable TDX > > > > in the future? Either by changes to KVM or the TDX module? > > > > > > AFAICT we haven't received such requirement so far. Let me double check > > > internally and get back here. > > > > > > Btw, if we want to do this purely from software, changing KVM isn't the > > > right thing to do. We need to somehow pass key data structures managing > > > TDX module to the second kernel, e.g., module status, locations of > > > PAMTs. And the second kernel needs to be modified to understand those, > > > which means some old (second) kernels with TDX support may not be able > > > to support this even if we add this to the kernel. > > > > Would it be possible to tear down the tdx module and re-initialize it > > on the next kernel? I don't think there's a requirement for the tdx > > module data structures to remain intact during kexec but it could be > > useful if tdx can be enabled on the new kernel. > > We discussed this internally. The TDX module cannot be re-initialized after > torn down. However the new kernel can reload the (same) TDX module and re- > initialize it (the P-SEAMLDR supports reload or runtime update TDX module). > > However our primary focus is to enable baseline TDX support in upstream. For > TDX host kexec, at this stage we focus on: 1) enable both TDX and Kexec in the > Kconfig; 2) allow normal kexec and kdump to work when TDX is enabled. Making > the second kernel be able to use TDX is next-step plan. > > May I ask is there any real use case that requires the second kernel to be > able to use TDX at this stage? [Again in plaintext] Right now I don't think we have production requirements for kexec at all besides kdump support. Kexec from TDX enabled kernel to a non-TDX kernel definitely doesn't have a production requirement. It would be nice to be able to kexec to a TDX enabled kernel to speed up the development cycle instead of waiting for a full reboot but that's not a high priority at the moment.
On Mon, 2024-08-26 at 14:22 -0500, Sagi Shahar wrote: > On Sat, Aug 24, 2024 at 4:31 AM Huang, Kai <kai.huang@intel.com> wrote: > > > > On Fri, 2024-08-23 at 11:15 -0500, Sagi Shahar wrote: > > > On Mon, Aug 19, 2024 at 5:44 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > > > > > > > > > > > > > On 20/08/2024 10:28 am, Sagi Shahar wrote: > > > > > On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@intel.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 20/08/2024 9:21 am, Sagi Shahar wrote: > > > > > > > > Currently kexec() support and TDX host are muturally exclusive in the > > > > > > > > Kconfig. This series adds the TDX host kexec support so that they can > > > > > > > > work together and can be enabled at the same time in the Kconfig. > > > > > > > > > > > > > > I tried testing the kexec functionality and noticed that the TDX module > > > > > > > fails initialization on the second kernel so you can't actually kexec > > > > > > > between 2 kernels that enable TDX. Is that the expected behavior? Are > > > > > > > there future patches to enable that functionality? > > > > > > > > > > > > > > > > > > > Thanks for testing! > > > > > > > > > > > > Yes this is the expected behaviour. If the first kernel has enabled > > > > > > TDX, then the second kernel will fail to init TDX. The reason the first > > > > > > SEAMCALL to initialize TDX module in the second kernel will fail due to > > > > > > module having been initialized. > > > > > > > > > > > > However if the first kernel has not enabled TDX, the second kernel is > > > > > > able to enable it. > > > > > > > > > > Are there any plans to support both kernels being able to enable TDX > > > > > in the future? Either by changes to KVM or the TDX module? > > > > > > > > AFAICT we haven't received such requirement so far. Let me double check > > > > internally and get back here. > > > > > > > > Btw, if we want to do this purely from software, changing KVM isn't the > > > > right thing to do. We need to somehow pass key data structures managing > > > > TDX module to the second kernel, e.g., module status, locations of > > > > PAMTs. And the second kernel needs to be modified to understand those, > > > > which means some old (second) kernels with TDX support may not be able > > > > to support this even if we add this to the kernel. > > > > > > Would it be possible to tear down the tdx module and re-initialize it > > > on the next kernel? I don't think there's a requirement for the tdx > > > module data structures to remain intact during kexec but it could be > > > useful if tdx can be enabled on the new kernel. > > > > We discussed this internally. The TDX module cannot be re-initialized after > > torn down. However the new kernel can reload the (same) TDX module and re- > > initialize it (the P-SEAMLDR supports reload or runtime update TDX module). > > > > However our primary focus is to enable baseline TDX support in upstream. For > > TDX host kexec, at this stage we focus on: 1) enable both TDX and Kexec in the > > Kconfig; 2) allow normal kexec and kdump to work when TDX is enabled. Making > > the second kernel be able to use TDX is next-step plan. > > > > May I ask is there any real use case that requires the second kernel to be > > able to use TDX at this stage? > > [Again in plaintext] > > Right now I don't think we have production requirements for kexec at > all besides kdump support. Kexec from TDX enabled kernel to a non-TDX > kernel definitely doesn't have a production requirement. > > It would be nice to be able to kexec to a TDX enabled kernel to speed > up the development cycle instead of waiting for a full reboot but > that's not a high priority at the moment. Yeah agreed. But then let's do this as a future work after baseline TDX support is done.
© 2016 - 2026 Red Hat, Inc.