RE: [PATCH v3 14/21] qemu: Add FakeReboot support for TDX guest

-----Original Message----- From: Daniel P. Berrangé <berrange(a)redhat.com&gt; 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é <berrange(a)redhat.com&gt; > >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.qiang(a)intel.com&gt; > >> Signed-off-by: Zhenzhong Duan <zhenzhong.duan(a)intel.com&gt; > >> --- > >> 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

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.