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