On Mon, Dec 04, 2023 at 11:30:54AM +0100, Peter Krempa wrote: > On Mon, Dec 04, 2023 at 10:28:17 +0000, Daniel P. Berrangé wrote: > > On Mon, Dec 04, 2023 at 03:38:30AM +0000, Duan, Zhenzhong wrote: > > > > > > > > > >-----Original Message----- > > > >From: Jonathon Jongsma <jjongsma@xxxxxxxxxx> > > > >Sent: Saturday, December 2, 2023 6:30 AM > > > >Subject: Re: [PATCH rfcv3 00/11] LIBVIRT: X86: TDX support > > [...] > > > > If we use existing "fake reboot" in libvirt, qmp command "system_reset" isn't > > > supported for TDX guest, because TDX doesn't support resetting each register > > > of vcpu for security except in TDX debug mode. TDX guest will be shutdown > > > instead. > > > > I suspect the same probably applies to SEV. > > > > > >What other approaches did you consider to solve this issue? The changes > > > >to virsh adding a reconnect timeout option for the console command in > > > >particular feel hacky to me. > > > > > > One possible way I can think of is to let qemu do the kill/create job, > > > i.e. destroy TDX vcpus, create new one. This way we can utilize existing > > > "fake reboot" interface between qemu and libvirt. > > > > Yes, I do wonder if there's some reasonable way for QEMU to re-create the > > KVM VM from scratch, to make this hardware limitation more transparent > > for all mgmt apps. > > Wouldn't that imply the need to do the attestation once over? Yes. No matter what is done - fake reboot in QEMU, fake reboot in libvirt, or a fake reboot in the mgmt app - all will require attestation again. 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
