Re: [PATCH rfcv3 07/11] qemu: add hard reboot in QEMU driver

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

 



On Fri, Jan 12, 2024 at 09:20:19AM +0000, Duan, Zhenzhong wrote:
> 
> 
> >-----Original Message-----
> >From: Daniel P. Berrangé <berrange@xxxxxxxxxx>
> >Subject: Re: [PATCH rfcv3 07/11] qemu: add hard reboot in QEMU driver
> >
> >On Mon, Nov 27, 2023 at 04:55:17PM +0800, Zhenzhong Duan wrote:
> >> From: Chenyi Qiang <chenyi.qiang@xxxxxxxxx>
> >>
> >> Add the new flag
> >VIR_DOMAIN_REBOOT_HARD/VIR_DOMAIN_SHUTDOWN_HARD to
> >> carry out a hard reboot, which kills the QEMU process and creates a new
> >> one with the same definition.
> >
> >AFAICT, the _HARD flags cause it to issue a QEMU monitor
> >command todo an ACPI shutdown and then re-create QEMU.
> >
> >IOW, it seems like this is just the same as the existing
> >_ACPI flags, and so I'm not sure why we need any new
> >functionality at all.
> >
> >What is the existing ACPI shutdown & fake reboot not
> >able to achieve ?
> 
> ACPI shutdown & fake reboot send below QMP command in sequence:
> 
> "system_powerdown", "system_reset", "cont".
> 
> "system_reset" QMP command isn't supported by TDX for security reasons.
> So we have to kill old QEMU and re-create new one.

We are still doing the 'system_powerdown' step first though, to do a
graceful shutdown, before re-creating QEMU, and the powerdown is what
we refer to as "ACPI".

So I think we don't need new public API constants. We should still use
the _ACPI flag, and just "do the right thing" with choosing between
system_reset vs re-creating QEMU depending on whether TDX/SEV are
active.

That way the public API user experience is unchanged, only the internal
impl varies.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux