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(a)redhat.com>
> > >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 :|