>-----Original Message----- >From: Daniel P. Berrangé <berra...@redhat.com> >Subject: Re: [PATCH v3 14/21] qemu: Add FakeReboot support for TDX guest > >On Wed, Jul 09, 2025 at 09:44:42AM +0000, Duan, Zhenzhong wrote: >> >> >> >-----Original Message----- >> >From: Daniel P. Berrangé <berra...@redhat.com> >> >Subject: Re: [PATCH v3 14/21] qemu: Add FakeReboot support for TDX >guest >> > >> >On Mon, Jun 30, 2025 at 02:17:25PM +0800, Zhenzhong Duan wrote: >> >> Utilize the existing fake reboot mechanism to do reboot for TDX guest. >> >> >> >> Different from normal guest, TDX guest doesn't support system_reset, >> >> so have to kill the old guest and start a new one to simulate the reboot. >> >> >> >> Co-developed-by: Chenyi Qiang <chenyi.qi...@intel.com> >> >> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com> >> >> --- >> >> src/qemu/qemu_process.c | 80 >> >+++++++++++++++++++++++++++++++++++++++-- >> >> 1 file changed, 77 insertions(+), 3 deletions(-) >> > >> >One thing I noticed during testing is that when a guest crashes >> >during boot up eg via a triple-fault, we'll endlessly re-create >> >QEMU which is quite expensive as memory pages are >allocated/deallocated, >> >and also burn through domain ID values. >> >> Is it because you enabled SEPT #VE? What's your <on_crash> setting? > >The SEPT #VE config mistake was a later config problem - that one >did NOT cause reboots - the VM simply powered off. > >The thing causing my endless reboots is a bug exposed in a recent >EDK2 update in Fedora that is resulting in a triple-fault, which >in turns causes a CPU reset, and thus this reboot logic triggers. >We have not identified the cause of that EDK problem yet
I see. I think we don't have much to do for this. We are emulating same behavior as normal guest, though there are some overheads. > >https://bugzilla.redhat.com/show_bug.cgi?id=2376851 > >> >I'm not sure there's much (anything) we can do about these downsides >> >though. >> >> About the sept-ve-disable, it's a must for linux kernel, but may be not for >others. >> Maybe checking "TD misconfiguration: SEPT #VE has to be disabled", but it's >not clean code. >> Or maybe document it? > >In the common case users simply should not set the 'policy' >attribute value at all, in which case the default values >should result in SEPT #VE being disabled. > >My mistake was that I was playing with the configuration >and had set policy to 0x0 and then forgot I did this when >coming back later. OK. Thanks Zhenzhong
