Il mer 18 ago 2021, 12:31 Ashish Kalra <ashish.kalra@amd.com> ha scritto:

> Hello Paolo,
>
> On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> > On 16/08/21 17:13, Ashish Kalra wrote:
> > > > > I think that once the mirror VM starts booting and running the UEFI
> > > > > code, it might be only during the PEI or DXE phase where it will
> > > > > start actually running the MH code, so mirror VM probably still
> need
> > > > > to handles KVM_EXIT_IO when SEC phase does I/O, I can see PIC
> > > > > accesses and Debug Agent initialization stuff in SEC startup code.
> > > > That may be a design of the migration helper code that you were
> working
> > > > with, but it's not necessary.
> > > >
> > > Actually my comments are about a more generic MH code.
> >
> > I don't think that would be a good idea; designing QEMU's migration
> helper
> > interface to be as constrained as possible is a good thing.  The
> migration
> > helper is extremely security sensitive code, so it should not expose
> itself
> > to the attack surface of the whole of QEMU.
> >
> >
> One question i have here, is that where exactly will the MH code exist
> in QEMU ?
>
> I assume it will be only x86 platform specific code, we probably will
> never support it on other platforms ?
>
> So it will probably exist in hw/i386, something similar to "microvm"
> support and using the same TYPE_X86_MACHINE ?
>
> Also if we are not going to use the existing KVM support code and
> adding some duplicate KVM interface code, do we need to interface with
> this added KVM code via the QEMU accelerator framework, or simply invoke
> this KVM code statically ?
>

I would expect to be mostly separate. Once we get a second architecture we
may move part of it into TYPE_ACCEL_KVM, but that can come later and
probably it would still not reuse much code from the full-blown KVM code
that supports interrupts, MMIO and all that.

Paolo


> Thanks,
> Ashish
>
>