>-----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

Reply via email to